clay@uci.UUCP (News Administrator) (07/07/89)
I was looking in the .Admin directory at the xferstats file, and found most of the bytes/sec calculations were around 80 bytes/sec for 2400 baud transfers. The xferstats on the machine I was talking to had more reasonable numbers around 200 bytes/sec, which is what wall clock time had led me to believe. Anybody know why the number of seconds per transfer is wrong? This is the HDB shipped with SCO 386 2.3.1. -- Clayton Haapala ...!mmm!dicome!uci!clay Unified Communications Inc. "Declare your Point of Entry, Space Wanderer!" 3001 Metro Drive - Suite 500 "Canarsi -- where everyone looks the same." Bloomington, MN 55425 -- zappa
davidsen@sungod.crd.ge.com (William Davidsen) (07/11/89)
In article <96@uci.UUCP> clay@uci.UUCP (News Administrator) writes: | Anybody know why the number of seconds per transfer is wrong? This is the HDB | shipped with SCO 386 2.3.1. It was compiled for a PC (8088) using a HZ value of 20. The fixes have been posted a few times, I don't have them handy. You just need to patch the uucico value from 20 to 50 and it all works fine. Somebody please mail him the patches? bill davidsen (davidsen@crdos1.crd.GE.COM) {uunet | philabs}!crdgw1!crdos1!davidsen "Stupidity, like virtue, is its own reward" -me
frankb@usource.UUCP (Frank Bicknell) (07/14/89)
In article <1149@crdgw1.crd.ge.com> davidsen@crdos1.UUCP (bill davidsen) writes: >In article <96@uci.UUCP> clay@uci.UUCP (News Administrator) writes: > >| Anybody know why the number of seconds per transfer is wrong? >| This is the HDB shipped with SCO 386 2.3.1. > >It was compiled for a PC (8088) using a HZ value of 20. >The fixes have been posted a few times, I don't have them >handy. You just need to patch the uucico value from 20 to 50 >and it all works fine. I was fortunate enough to find the source code laying about and found where 'HZ' is compiled in. It turns up in only one place for a Xenix compile (there's one other place where it sleeps an amount of time dependent on HZ for BSD 4.2). Anyway, it is found in the function 'millitick', and one can patch uucico as follows (note: I did this on Xenix 2.3.1... I don't know if this address is valid for 2.3.2, but it might be): $ # assuming that we're uucp here $ cd /usr/lib/uucp $ mv uucico uucico.org $ cp uucico.org uucico $ adb -w uucico * millitick+32?i _millitick+0x32: mov ax,0x14 # 1 * ?x _millitick+0x32: 0x14b8 # 2 * ?w32b8 _millitick+0x32: 0x14b8= 0x32b8 # 3 * <^D> $ Notes: 1) This value, 0x14 represents the original HZ value of 20, decimal. If it already says 0x32, you can press ^D now to quit. 2) This represents the 'mov ax,0x14' instruction (or at least part of it) in hex. We want to change the 14. 3) This is the confirmation we want that says the 14 was changed to 32 (50 decimal). >Somebody please mail him the patches? I hope this doesn't tread on anyone's toes to post this. -- Frank Bicknell UniSource; 1405 Main St, Ste 709; Sarasota, FL 34236 killer!usource!frankb || frankb@usource.UUCP