
                    -= NetFoss 0.9.1 upgrade notes =-

                             June 13, 2004

____________________________________________________________________________




   After a very long break, NetFoss is back in development....
 


 Prior to this month, the last official release of NetFoss was version
 0.8.1, released in December 2002. After that release I rewrote the
 Communication Engine for better performance and CPU usage, and to support
 binary transfers. An "experemental beta" Communication engine was
 released to the public in January 2003, and soon afterwards development
 was put on hold due to many other priorities in my life (i.e: work,
 house repairs, kids, wife).

 I never expected the pause to last a year and a half, but time flew by.
 I recently started finding a little free time, and last month I was
 coding an ANSI driver that redirects standard I/O to a FOSSIL driver.
 Then a few weeks ago a sysop named Doug Rhee reported that some of
 his doors didnt work under NetFoss, so i desided to find the cause.
 Doug runs hundreds of doors on his BBS, and has joined the few remaining
 members of the beta team during the past week to test several versions.
 

 Most of the issues turned out to be due to a few doors not following the
 FOSSIL specs, and after working around the problems, I tweaked some of
 the other code in both NetFoss and NetCom.

____________________________________________________________________________


 Upgrading from 0.85wb or later:
 ===============================

 Simply replace the NETFOSS.COM, NETFOSS.DLL, and NETCOM.EXE with the
 new versions.

 *IMPORTANT* :
 When upgrading, remember to upgrade all copies of NETFOSS.DLL on
 your hard drive to the new version. This file must be located
 somewhere in your system %PATH% in order to be found.
 If you copied your old NETFOSS.DLL to c:\windows\system32 for
 example, then be sure to upgrade it with the new version.

____________________________________________________________________________


 Upgrading from 0.81 or earlier:
 ===============================




 This version of the Communication Engine (NetCom) might require fine
 tuning in order to achive the lowest possible CPU usage. Most doors
 should idle at around 0% to 5% CPU usage per node.
 (On a P4 class CPUs it should idle between 0% to 1%)

 One person outside the beta team reported getting 30% CPU usage on an
 Athlon XP2000 using the default settings, while a beta tester running
 an Athlon XP1800 reported it ran at 0%.

 If you are upgrading from a previous version such as 0.8.1, then
 I suggest you first check the amount of CPU usage occurs when you
 have one DOS session running under NetFoss, idling at a prompt.
 Press Ctrl-Alt-Del for the task manager, and then click
 on the Performance tab to see the CPU usage.

 Also you should make a mental note of how quickly full ANSI screens
 are displayed on the remote telnet terminal.  Then upgrade to the new
 version of NETFOSS.COM, NETCOM.EXE, and NETFOSS.DLL.

 *IMPORTANT* :
 When upgrading, remember to upgrade all copies of NETFOSS.DLL on
 your hard drive to the new version. This file must be located
 somewhere in your system %PATH% in order to be found.
 If you copied your old NETFOSS.DLL to c:\windows\system32 for
 example, then be sure to upgrade it with the new version.

 Once you have installed the new files, telnet to localhost again
 and compare the results for yourself. If you find that the new
 version is slower or uses more CPU then 0.8.1 did, then you may
 need to adjust the settings by using the following NetCom command
 line parameters:

 ---------------------------------------------------------------------
      /S{time till sleep}       default= 20
      /B{buffer minimum bytes}  default= 384
      /W{write delay time}      default= 1500
      /X
 ---------------------------------------------------------------------

 Example:  NETCOM /S20 /B384 /W1500 %1 %2 %3 %4 %5 %6 %7 %8 %9

 /S{value} = The amount of time NetCom should wait before releasing idle
             time to Windows. If your CPU usage is too high, then try
             lowering this value. Increasing the value will increase
             response time unless the CPU usage gets too high.

 /W{value} = The maximum amount of time to wait before sending the
             buffered TCP/IP packet to Winsock.

 /B{value} = The maximum amount of outgoing data to buffer before
             sending the TCP/IP packet to Winsock.

 /X =        Forces old timing mode from version 0.8.1 and earlier.
             This will ignore any /S and /W settings. No value
             is needed.
 

 The /S parameter is probally the only paremeter you may need to fine-tune,
 as adjusting its value can yield considerably better performance or lower
 CPU usage or even both...

 On my Toshiba Satellite P4 2.0Ghz, a setting of /S10 works best (0%),
 while on my CTX K6-2 300Mhz EZBook a setting of /S40 works best (3%).
 Both still work well at the default setting of 20.
 On my PIII 1.2Ghz Desktop, those defaults caused 30% CPU usage, and
 changing the setting to /S12 brought it down to 1%.

 Note that the /B and /W settings both determine how much buffering is
 done before sending (writing) a tcp/ip packet. Both values are in
 tenths of milliseconds, By default, NetCom will wait for 150
 milliseconds after the first data to be written comes from NetFoss,
 or when 384 bytes are buffered, which ever occurs first.
 I suggest you leave both of these alone. Setting a higher delay or
 buffer size could lead to a choppy remote display and poor response
 time. A lower setting could cause smaller packets resulting in less
 performance most noticeable on slower connections. However if you do
 experience choppiness or poor response time on the remote side then
 lowering these might help.

 If you do not specify /S /B or /W values on the command line, the
 default values listed above will be used.


 If you use the /X parameter, then any /S and /W values are ignored,
 and the old timing (from versions 0.8.1 and earlier) are used. Use
 this if you cant get a low CPU usage using the high performance
 counters.


------------------------------------------------------------------------------


 If you find that this version does not perform as well on your computer
 as version 0.8.1, or you found that you needed to adjust the above settings
 to get better performance, then please let me know.


 Please send bug reports and comments to mike@pcmicro.com.
 Thanks!
