We have seen a problem with the 4.25 TCP stack that was not apparent with
earlier versions of the stack (We have had a fair amount of experience with
the 4.24 stack)
We send a large buffer (>8000 bytes) with a single send request at the ‘C’
socket level…
Almost immediately, the TCP stack send out a minimum of a single frame;
sometimes several frames.
However, the window size does not get exhausted nor do the entire queued
data bytes get transmitted.
Before any more frames are sent, the QNX TCP stack seems to go to sleep.
An ack message from the peer system will “wake up” the stack and some
additional message(s) will then be transmitted.
This goes on, taking much longer that necessary to transfer data to a peer.
But if (in a bad network condition situation) the ACK response is lost, the
delay will become very noticable, with timeouts and retransmissions
sometimes taking > 10 seconds for a single message.
This seems to be a problem in 4.25. This did not seem to be problem (ar at
least not as pronounced) in the QNX 4.24 version that we replaced.
What is the availability of a stack (Beta or otherwise) which will fix this
problem?
I believe that this may be related to or the same problem as reported
earlier (1/26/2001).
Thanks,
Jim Johnson
PS: We also see that there is much (3x to 10x) slower response to Phindows
1.20 by this 4.25 stack. I am not sure if this is related or we need to
look for another cause.
This problem should be fixed in the TCP/IP RT 5.0 which isn’t released yet. I can’t give you a timeline on when it will be released but I can tell you that a beta is avaliable if you are a member of our beta group. If you are not a member of our beta group then you can get information about joining the beta group by going to:
We have seen a problem with the 4.25 TCP stack that was not apparent with
earlier versions of the stack (We have had a fair amount of experience with
the 4.24 stack)
We send a large buffer (>8000 bytes) with a single send request at the ‘C’
socket level…
Almost immediately, the TCP stack send out a minimum of a single frame;
sometimes several frames.
However, the window size does not get exhausted nor do the entire queued
data bytes get transmitted.
Before any more frames are sent, the QNX TCP stack seems to go to sleep.
An ack message from the peer system will “wake up” the stack and some
additional message(s) will then be transmitted.
This goes on, taking much longer that necessary to transfer data to a peer.
But if (in a bad network condition situation) the ACK response is lost, the
delay will become very noticable, with timeouts and retransmissions
sometimes taking > 10 seconds for a single message.
This seems to be a problem in 4.25. This did not seem to be problem (ar at
least not as pronounced) in the QNX 4.24 version that we replaced.
What is the availability of a stack (Beta or otherwise) which will fix this
problem?
I believe that this may be related to or the same problem as reported
earlier (1/26/2001).
Thanks,
Jim Johnson
PS: We also see that there is much (3x to 10x) slower response to Phindows
1.20 by this 4.25 stack. I am not sure if this is related or we need to
look for another cause.
\