Peter Dowson
01-06-2005, 10:25 AM
Hi folks,
It seems that the changes made recently to WideFs, whilst most certainly
providing a measurable improvement in performance for most, is causing some
problems for a minority.
Attached to this Announcement is a ZIP containing a revised WideServer and
WideClient, both at version 6.442, for you to try.
Please do not use these unless you are willing to check Log files regularly
and report any findings, good or bad. I don't need to know if things "stay
the same", only if they are better, or worse, or if there are error reports
or weird things in the logs.
For large logs please ZIP them and send them to me at
petedowson@btconnect.com. Include the WideClient.ini and WideServer.ini files too, please, and a
brief description of what you see.
Please also try the default values for the parameters, at least initially. I
need to get those values correct for the vast majority of users.
Here are the changes since version 6.44:
1. The client send queue parameters and checks are revised in order to try
to eliminate the occurrence of multiple reconnections due to excessive send
queue build-ups on some folks systems. The reason for the build-ups has not
been determined, because I cannot make them happen at all on any of my
set-ups. The changes are:
(a) The check is now controlled by the parameter OnMaxSendQ, which
automatically replaces the previous one, and this defaults to "Log", which simply
logs the excessive queue and does nothing about it. Other values possible here
are "Flush" which flushes the queue, and "Recon" which reconnects as well
as flushing the queue. The last is the action that was occurring in 6.44.
The danger is reconnecting is that the same problem immediately recurs, as
on a reconnection all the request read data has to be re-requested, as if
the client is a new one.
(b) The SendScanTime parameter, which defaulted to 10, is replaced by
NewSendScanTime, which defaults to 50. This limits the number of send queue scans
to 20 per second, but it now does not limit the number of frames sent. Each
single scan will send as many queued frames as it can before the Windows
network indicates that one will block.
(c) The ApplicationDelay implementation is changed to make the timing more
accurate. Previously the value of 6, for instance, could have actually given
rise to a delay of anything from 6 to 55, because of the granularity of the
timer being used. The greater accuracy should make things run smoother
still, but, now, to guarantee an average which approximates to the delays in
WideClient 6.41 and before, the value would have to be set to something like
25.
I recommend strongly, however, that this parameter is left to its default of
0. If you have increased this in an attempt to get over problems, please
restore it to 0 and see if the problems are better dealt with by the
NewSendScanTime change above.
2. WideClient now logs interim performance data as well as final performance
data when closed. The interim values are logged whenever the Server sends
out any type of Close message that doesn't actually result in the Client
closing. For instance, if the AutoShutdown parameter in the Server is set to
"Apps" then, even if application closure is not allowed in the client, it
will still log the performance so far when FS is closed.
3. WideClient performance data now includes the maximum and average send
data (frames and bytes). You will find that the averages tend to be
surprisingly low, peaking really soon after connection (and reconnection) or when
new applications are started. Upon closure, WideServer also logs an overall
average "received" data line for every separate client which has been
connected, but this is averaged over the whole session so the figures will tend
to be less than those shown at the Client.
4. WideClient now sends its version number to the Server along with the
Client PC name. This is logged by WideServer in the connection message and is a
useful way to check that you do have all client PCs up to date. So that
programs like the PM file checker can check this easily too, the lowest
WideClient version number is provided in the 16-bit word at offset 3520, as the
version number x 1000 in binary-coded decimal (BCD), e.g. hex 6450. If
WideServer is out of date (before 6.442), or any one WideClient is earlier than
6.442, then offset 3520 will be zero.
5. WideServer now provides the IPXROUTE data (with decoded ServerNodes) if
the main details returned to it by Windows has a non-zero Network Number and
a suspicious-looking MAC address for the adapter.
6. Error trapping has been added to many parts of WideClient. This is in
response to two separate reports of WideClient crashing-for one user without
even an error message, and for another with the usual Windows error report.
The error trapping may mean that, instead of crashing, WideClient will stay
running in spite of experiencing the problem that caused the crash.
Whether it continues to run correctly thereafter is unknown, however, because the
reason for the crash is unknown. It may get stuck in a loop continually
crashing, and generating a large log in the process.
I need to find the cause of these crashes and fix it. In the many years since
WideFS was first released (for FS98) I have not had such a problem, and I
cannot reproduce it here. So please, all users, always check the WideClient
logs after a session, or during a session if anything odd happens. I would
dearly love to see a log with the trapped error details so I can nail
this.
Regards,
Pete Dowson
6th January 2005
It seems that the changes made recently to WideFs, whilst most certainly
providing a measurable improvement in performance for most, is causing some
problems for a minority.
Attached to this Announcement is a ZIP containing a revised WideServer and
WideClient, both at version 6.442, for you to try.
Please do not use these unless you are willing to check Log files regularly
and report any findings, good or bad. I don't need to know if things "stay
the same", only if they are better, or worse, or if there are error reports
or weird things in the logs.
For large logs please ZIP them and send them to me at
petedowson@btconnect.com. Include the WideClient.ini and WideServer.ini files too, please, and a
brief description of what you see.
Please also try the default values for the parameters, at least initially. I
need to get those values correct for the vast majority of users.
Here are the changes since version 6.44:
1. The client send queue parameters and checks are revised in order to try
to eliminate the occurrence of multiple reconnections due to excessive send
queue build-ups on some folks systems. The reason for the build-ups has not
been determined, because I cannot make them happen at all on any of my
set-ups. The changes are:
(a) The check is now controlled by the parameter OnMaxSendQ, which
automatically replaces the previous one, and this defaults to "Log", which simply
logs the excessive queue and does nothing about it. Other values possible here
are "Flush" which flushes the queue, and "Recon" which reconnects as well
as flushing the queue. The last is the action that was occurring in 6.44.
The danger is reconnecting is that the same problem immediately recurs, as
on a reconnection all the request read data has to be re-requested, as if
the client is a new one.
(b) The SendScanTime parameter, which defaulted to 10, is replaced by
NewSendScanTime, which defaults to 50. This limits the number of send queue scans
to 20 per second, but it now does not limit the number of frames sent. Each
single scan will send as many queued frames as it can before the Windows
network indicates that one will block.
(c) The ApplicationDelay implementation is changed to make the timing more
accurate. Previously the value of 6, for instance, could have actually given
rise to a delay of anything from 6 to 55, because of the granularity of the
timer being used. The greater accuracy should make things run smoother
still, but, now, to guarantee an average which approximates to the delays in
WideClient 6.41 and before, the value would have to be set to something like
25.
I recommend strongly, however, that this parameter is left to its default of
0. If you have increased this in an attempt to get over problems, please
restore it to 0 and see if the problems are better dealt with by the
NewSendScanTime change above.
2. WideClient now logs interim performance data as well as final performance
data when closed. The interim values are logged whenever the Server sends
out any type of Close message that doesn't actually result in the Client
closing. For instance, if the AutoShutdown parameter in the Server is set to
"Apps" then, even if application closure is not allowed in the client, it
will still log the performance so far when FS is closed.
3. WideClient performance data now includes the maximum and average send
data (frames and bytes). You will find that the averages tend to be
surprisingly low, peaking really soon after connection (and reconnection) or when
new applications are started. Upon closure, WideServer also logs an overall
average "received" data line for every separate client which has been
connected, but this is averaged over the whole session so the figures will tend
to be less than those shown at the Client.
4. WideClient now sends its version number to the Server along with the
Client PC name. This is logged by WideServer in the connection message and is a
useful way to check that you do have all client PCs up to date. So that
programs like the PM file checker can check this easily too, the lowest
WideClient version number is provided in the 16-bit word at offset 3520, as the
version number x 1000 in binary-coded decimal (BCD), e.g. hex 6450. If
WideServer is out of date (before 6.442), or any one WideClient is earlier than
6.442, then offset 3520 will be zero.
5. WideServer now provides the IPXROUTE data (with decoded ServerNodes) if
the main details returned to it by Windows has a non-zero Network Number and
a suspicious-looking MAC address for the adapter.
6. Error trapping has been added to many parts of WideClient. This is in
response to two separate reports of WideClient crashing-for one user without
even an error message, and for another with the usual Windows error report.
The error trapping may mean that, instead of crashing, WideClient will stay
running in spite of experiencing the problem that caused the crash.
Whether it continues to run correctly thereafter is unknown, however, because the
reason for the crash is unknown. It may get stuck in a loop continually
crashing, and generating a large log in the process.
I need to find the cause of these crashes and fix it. In the many years since
WideFS was first released (for FS98) I have not had such a problem, and I
cannot reproduce it here. So please, all users, always check the WideClient
logs after a session, or during a session if anything odd happens. I would
dearly love to see a log with the trapped error details so I can nail
this.
Regards,
Pete Dowson
6th January 2005