Record locking

[Brian K. White]

Mike Schwartz-PC Support & Services wrote:
>> As I insinuated earlier, there were three potential users working
>> simultaneously and all of them could have had the same number since
>> the network/windows was holding the changes in cache rather than
>> immediately writing back to the files on the station that was acting
>> as server as soon as one station had asked for a new number.  There
>> was enough lag --
>> William Akers
>
> John is still not used to thinking in terms of "Windows", although
> PFSYNC and the other things we have discussed do help the Windows
> caching problems (but don't necessarily cure them).  I don't recall
> seeing these problems occur on any of the Unix systems I've worked
> with.
>
> I don't necessarily think it's all Windows fault, because there will
> inevitably be timing issues as we try to run old code on faster
> machines. Just try and pull out an old copy of Xenix and run it on a
> brand new computer.  Xenix did a lot of things via timing loops, and
> it would probably fail miserably on new hardware.

Heh, No probably about it. Known, documented, verified.
486 dx2-80 is about the fastest thing you can use and even that is iffy
depending on the rest of the system.
not to mention the other limits unrelated to timing like 16 megs of ram in
the universe and 512 megs per filesystem.

I had to jazz up a xenix ox as much as I could to keep it alive a little
longer while a whole new system with different software was in the works and
was so amazed at how much faster the machine was after:
8 megs 80ns ram  to 16 megs 60ns
intel 486 sx 33 to  amd 486 dx2-80
half-height 320 meg ide to standard 3.5" 1.2gig ide (with all speed specs
faster but I don't remember the actual numbers)

"Wow! this report usually takes about an hour and it's _flying_ in about 35
minutes! Amazing!"

2 months later the same exact report in the same exact software, runing on
the new OSR 5.0.5 box with a PII-350 and 9 gig scsi and 256megs of probably
pc66 sdram runs in about 5 minutes even while everyone is actively busy
working in the new filepro software on the same box.

Nowadays, (at least in the windows world)  it seems like every new machine
with specs that say it should run twice as fast as the last, actually runs
slower than the last. It's not just windows either. Linux distro's all tend
to install enough gnome or kde stuff in their default "desktop" installs to
bog any machine down in the finest windows tradition. Even if you "clean out
the crap" from your new factory windows install, or re-install fresh leaving
out the crap, it's still never exactly "fast" just "not as slow".

Brian K. White  --  brian at aljex.com  --  http://www.aljex.com/bkw/
+++++[>+++[>+++++>+++++++<<-]<-]>>+.>.+++++.+++++++.-.[>+<---]>++.
filePro BBx  Linux SCO  Prosper/FACTS AutoCAD  #callahans Satriani