Hi Jeroen, on Saturday, 2006-04-22 at 22:26:43, you wrote: > >Lacking any benchmarks from before the change, that's the best measure I > >have. It might have been the firmware upgrade, but I doubt it. If I have > >to reboot any time soon, maybe I'll do another test to verify it. > > > Rrright.. that's the big disadvantage of having to sort this stuff out > on a production machine :) > We're only now starting to convince (read: force) our developers *not > *to put live code on production systems /before /we have had a chance to > test it. > You know how it goes...
Sure...actually I tested most of the installation on another machine before switching it over to the server, but it didn't have quite the same hardware. This is a fairly small university department so we just can't justify a second ProLiant box for the occasional upgrade :) > Still only 300mbits, though... a server like that should be able to > handle SSH at near-line speed. Yup...that one hasn't been faster before either though. > >OK, that was a bit misleading, I meant that even assuming things about > >the flat file the scheduler sees of the disk like that offsets in the > >file sort of linearly correspond to cylinders > That *may* be true for old IDE drives, but it isn't even remotely true > for SCSI, which is its own higher-level abstraction on top of the > physical drive interface already, Huh? OK, block remapping for error recovery and stuff, but usually you can observe in benchmarks how the transfer rate corresponds to the offset, just like you'd expect it if the offset corresponded to the cylinder. > not to mention the layer the SmartArray puts on top of /that/. Sure. That's why I was thinking of the NOOP scheduler. > >---which is what it does to > >implement things like the elevator algorithm---are virtually always > >right for simple drives but may not be for a RAID. > > > Erm.. that's what I said :) Me too :) Just haven't benchmarked NOOP yet but I'm gonna try. Thanks for your input, I'll ask if we can afford the BBWC module...not that anybody was crying for it, but an admin needs a new toy once in a while as well! cheers! Matthias -- I prefer encrypted and signed messages. KeyID: FAC37665 Fingerprint: 8C16 3F0A A6FC DF0D 19B0 8DEF 48D9 1700 FAC3 7665
pgpQ2u9LiehOQ.pgp
Description: PGP signature
