Date: Mon, 4 Sep 2000 23:21:33 +0200 (CEST) From: =?ISO-8859-1?Q?G=E9rard_Roudier?= <groudier@club-internet.fr> To: freebsd-scsi@FreeBSD.org Subject: New `sym' driver version for testing. Message-ID: <Pine.LNX.4.10.10009042251580.522-100000@linux.local>
next in thread | raw e-mail | index | archive | help
Hello, I just made avalaible a new version of the `sym' driver. You can download it from the following URL: http://people.freefall.org/~groudier/sym-1.7.0-20000904.tar.gz There are no new features in this driver version. I just flushed all the simplifications and optimizations I had in mind, prior to adding new functionnalities in the driver. You must be aware that this driver version is still experimental. I haven't yet written the change-log against driver version in -current, but I will do it in a couple of days. The only thing I can say at the moment is that, based on my calculations, the I/O latency should still have won a couple of micro-seconds. People that use stupid `one IO at a time' benchmarks to measure latency must know that a lower latency not always make results of these benchmarks better. If you experience such a weird result, you may, for example manually add some delay in the driver and I bet you will make your stupid benchmark happy. For example, you may hack the driver in that place: (Exemple for 50 micro-second latency) /* * SIM action entry point. */ static void sym_action(struct cam_sim *sim, union ccb *ccb) { - int s = splcam(); + int s; + UDELAY(50); + s = splcam(); sym_action1(sim, ccb); splx(s); } With some old hardisks, adding a > 100 micro-second latency, can also give best `stupid latency benchmark' results. Btw, donnot run your system with such an ugly hack for real work. ;-) If I ever receive a report that proves that adding latency can make stupid latency benchmarks give better results in some special situation, then I may well try to explain why. :-) Gérard. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.LNX.4.10.10009042251580.522-100000>