Test version 6.442 of WideFS

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

Hello Peter,

thanks for this update...

I have also uploaded pmFileCheck 25 to www.projectmagenta.com/updates.html

- it will check for WideFS/WideClient versions on the network (*)
- it will read the WideServer Log for the sequence of client connections
- it has a small feature to check selected offsets for troubleshooting
- some re-formatting took place and additional info added

(*) this is to help exclude that there are precambrean versions of
WideClient running on your network

Ciao

Enrico

"Peter Dowson" wrote in message
news:281586.55977@wb.onvix.com...
> 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
>



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


>

oops... "precambrian".

Ciao

Enrico

"Enrico Schiratti" wrote in message
news:281616.55977@wb.onvix.com...
> Hello Peter,
>
> thanks for this update...
>
> I have also uploaded pmFileCheck 25 to
www.projectmagenta.com/updates.html
>
> - it will check for WideFS/WideClient versions on the network (*)
> - it will read the WideServer Log for the sequence of client connections
> - it has a small feature to check selected offsets for troubleshooting
> - some re-formatting took place and additional info added
>
> (*) this is to help exclude that there are precambrean versions of
> WideClient running on your network
>
> Ciao
>
> Enrico
>
> "Peter Dowson" wrote in message
> news:281586.55977@wb.onvix.com...
>> 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
>>
>
>
>
>
--------------------------------------------------------------------------------
>
>
>>
>