In the light of the recent bench­mark dis­cus­sion, a vol­un­teer imported the tun­ing man-page into the wiki. Some com­ments at some places for pos­si­ble improve­ments are already made. Please go over there, have a look, and par­tic­i­pate please (testing/verification/discussion/improvements/…).

As always, feel free to reg­is­ter with First­name­Last­name and tell a FreeBSD com­mit­ter to add you to the con­trib­u­tors group for write access (you also get the ben­e­fit to be able to reg­is­ter for an email noti­fi­ca­tion for spe­cific pages).

Today I have read an inter­est­ing inves­ti­ga­tion and prob­lem analy­sis from Jim Get­tys.

It is a set of arti­cles he wrote over sev­eral months and is not fin­ished writ­ing as of this writ­ing (if you are deeply inter­ested in it go and read them, the most inter­est­ing ones are from Decem­ber and Jan­u­ary and the com­ments to the arti­cles are also con­tribut­ing to the big pic­ture). Basi­cally he is telling that a lot of net­work prob­lems users at home (with ADSL/cable or WLAN) expe­ri­ence  are because buffers in the net­work hard­ware or in oper­at­ing sys­tems are too big. He also pro­poses workarounds until this prob­lem is attacked by OS ven­dors and equip­ment manufacturers.

Basi­cally he is telling the net­work con­ges­tion algo­rithms can not do their work good, because the net­work buffers which are too big come into the way of their work (not report­ing packet loss timely enough respec­tively try to not lose pack­ets in sit­u­a­tions where packet loss would be bet­ter because it would trig­ger action in the con­ges­tion algorithms).

He inves­ti­gated the behav­ior of Linux, OS X and Win­dows (the sys­tem he had avail­able). I wanted to have a quick look at the sit­u­a­tion in FreeBSD regard­ing this, but it seems at least with my net­work card I am not able to see/find the cor­re­spond­ing size of the buffers in dri­vers in 30 seconds.

I think it would be very good if this issue is inves­ti­gated in FreeBSD, and apart from maybe tak­ing some action in the source also write some sec­tion for the hand­book which explains the issue (one prob­lem here is, that there are sit­u­a­tions where you want/need to have such big buffers and as such we can not just down­size them) and how to bench­mark and tune this.

Unfor­tu­nately I even have too much on my plate to even fur­ther look into this. I hope one of the net­work peo­ple in FreeBSD is pick­ing up the ball and starts playing.

Last week my ZFS cache device — an USB mem­ory stick — showed xxxM write errors. I got this stick for free as a promo, so I do not expect it to be of high qual­ity (or wear-leveling or sim­i­lar life-saving things). The stick sur­vived about 9 months, dur­ing which it pro­vided a nice speed-up for the access to the cor­re­spond­ing ZFS stor­age pool. I replaced it by another stick which I got for free as a promo. This new stick sur­vived… one long week­end. It has now 8xxM write errors and the USB sub­sys­tem is not able to speak to it any­more. 30 min­utes ago I issued an “usb­con­fig reset” to this device, which is still not fin­ished. This leads me to the ques­tion if such sticks are really that bad, or if some prob­lem crept into the USB subsystem?

If this is a prob­lem with the mem­ory stick itself, I should be able to repro­duce such a prob­lem on a dif­fer­ent machine with a dif­fer­ent OS. I could test this with FreeBSD 8.1, Solaris 10u9, or Win­dows XP. What I need is an auto­mated test. This rules out the Win­dows XP machine for me, I do not want to spend time to search a suit­able test which is avail­able for free and allows to be run in an auto­mated way. For FreeBSD and Solaris it prob­a­bly comes down to use some disk-I/O bench­mark (I think there are enough to chose from in the FreeBSD Ports Col­lec­tion) and run it in a shell-loop.