Results 1 to 3 of 3
  1. #1
    Peter Dowson
    Guest

    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 FS9 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


  2. #2
    Enrico Schiratti
    Guest

    Re: Test version 6.442 of WideFS

    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 FS9 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
    >




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


    >



  3. #3
    Enrico Schiratti
    Guest

    Re: Test version 6.442 of WideFS

    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 FS9 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
    >>

    >
    >
    >
    >

    --------------------------------------------------------------------------------
    >
    >
    >>

    >



Similar Threads

  1. New Build with NAV TEST and WX TEST - Question!
    By Jan Pemöller in forum PM Boeing GC
    Replies: 7
    Last Post: 05-11-2010, 02:26 PM
  2. FSUIPC: replacement test version 3.424
    By Peter Dowson in forum PM General Q & A
    Replies: 4
    Last Post: 11-25-2004, 10:26 AM
  3. Revised test version of wideFS (6.414)
    By Peter Dowson in forum PM General Q & A
    Replies: 8
    Last Post: 11-24-2004, 07:20 PM