Silicon Investor (SI) -- The First Internet Community

STOCKTALK

We've detected that you're using an ad content blocking browser plug-in or feature. Ads provide a critical source of revenue to the continued operation of Silicon Investor. We ask that you disable ad blocking while on Silicon Investor in the best interests of our community. If you are not using an ad blocker but are still receiving this message, make sure your browser's tracking protection is set to the 'standard' level.

Technology Stocks : CYRIX / NSM -- Ignore unavailable to you. Want to Upgrade?

To: Joe NYC who wrote (30021)	10/22/1998 11:19:00 PM
From: Craig Freeman	Read Replies (1) \| Respond to of 33344

Jozef, re: "No disk access. The entire database fits in the disk cache of the server". Unless your are the only user at the time, it takes almost exactly the same number of milliseconds to access a cached database as an uncached database. That is because Windows usually permits local caching only until a second user joins the action. And networks are often slower than hard drives (esxpecially at 10BaseT speeds). The first test is to take a 10MB+ file and use DOS to type COPY c:\XXX.XXX F:\xxx.xxx and time it. If it takes more than a second, you have network troubles. Never trust a cable until it has been replaced! As to "remote possibilities", CPQ isn't perfect either. But if you start with the assumption that a true MHz is a true MHz, the CPQ help desk will understand and help you to get all 350 of them. Whatever you experienced at 188MHz with CYRX, should almost double with your new PIIs. THAT should be you minimum goal. I would wish you luck but, from experience, I know how much more it takes. Here's hoping that "THEY" can get it to work before you are ready to chuck it all. Whoever said that Windows was a Godsend surely came from below. And whoever said that Intel made it all possible, was named Paul. Craig

To: Joe NYC who wrote (30021)	10/28/1998 4:31:00 AM
From: Craig Freeman	Read Replies (1) \| Respond to of 33344

Jozef, re: "No disk access. The entire database fits in the disk cache of the server." During the 486 era, I tested several Novell networks and discovered that it can take longer to "lock" a record than to load it .. even with unlimited server cache. There are lots of ways Novell can lock records but the most common method is SLOOOW. If your software erroneously issues extraneous locks, it will run slowly no matter what kind of CPU, O/S or file server in use. Under NT, if you are the only user then it automatically performs "local caching" which eliminates the need for all locks. Novell lacks this ability. Therefore, with identical workstations and server hardware, a Novell network may provide around ~600KBS throughput while an NT server can provide 12,000KBS throughput with a typical 300MHz CPU. To some, that means that "NT" is 20 times faster than Novell. Wrong! The instant you add another station addressing the same file, Novell starts to rev and NT dies down. As you add stations, the benchmarks change according to more causes than I could possibly explain here. And while NT can be futzy, Novell 3.12 is absolutely bulletproof (no comment here on Novell 4x+). Unless you are VERY careful, network benchmarks can be totally meaningless. About all that you can be sure of is that if you are the only user on a network, a cached read or a write into server cache should take place at 60-90% of the theoretical network speed (600-900KBS for 10BaseT, around 6,000KBS for 100BaseT). The usual test is to open a DOS box and locate a file of a MB or more. Type COPY C:xxxx F:\ and see how long it takes before your prompt returns. Anything fancier -- like TPS testing is ... well ... fancier but not necessarily meaningful. Craig