Slow links and tcpip

Hi all:

I’ve got a great tcp question. :slight_smile:

There is a Windows ras server dialling to a number of remote QNX boxes. The
link is via radio. The radios are designed for nasty environments and
changing propagation conditions, when a link is established it stays
established. However they are half duplex and NB they switch between tx and
rx once per second! Yes even though the bit rate is 2400, for 1 second you
receive and then for 1 second you transmit. For tcpip this is a packet per
second throughput or packet and ack in under 2 seconds.

For the simple protocol that they used in the past, this was ok. Now they
want to use tcpip. We have setup the Windows and QNX sides to work perfectly
with normal modems, however when we replace the modems with the radios no
joy. It nearly works, the link is established and ip addresses are assigned
at both ends, its just that the very last part of the arbitration isn’t
completed and the QNX box keeps attempting to reset the QNX boxes default
route.

So my question is, is there a way to adjust the timings in the tcp stack so
that a link this slow will work?

I have noted a tcp_nodelay parameter for sockets that tries to send as many
packets at once, but this seems to apply only to a socket. I need to do this
for the whole stack.

TIA
Andy

PS yes we are asking the manufacturer if the switching can be done more
quickly. No answer as yet.

Just a supporting note:

According to the radio supplier a slip connection will work. Is slip
supported in QNX 6.1.0 ?

Thanks.
Andy

“Andy” <andy@symmetry.com.au> wrote in message
news:ch5li0$maf$1@inn.qnx.com

Hi all:

I’ve got a great tcp question. > :slight_smile:

There is a Windows ras server dialling to a number of remote QNX boxes.
The
link is via radio. The radios are designed for nasty environments and
changing propagation conditions, when a link is established it stays
established. However they are half duplex and NB they switch between tx
and
rx once per second! Yes even though the bit rate is 2400, for 1 second you
receive and then for 1 second you transmit. For tcpip this is a packet per
second throughput or packet and ack in under 2 seconds.

For the simple protocol that they used in the past, this was ok. Now they
want to use tcpip. We have setup the Windows and QNX sides to work
perfectly
with normal modems, however when we replace the modems with the radios no
joy. It nearly works, the link is established and ip addresses are
assigned
at both ends, its just that the very last part of the arbitration isn’t
completed and the QNX box keeps attempting to reset the QNX boxes default
route.

So my question is, is there a way to adjust the timings in the tcp stack
so
that a link this slow will work?

I have noted a tcp_nodelay parameter for sockets that tries to send as
many
packets at once, but this seems to apply only to a socket. I need to do
this
for the whole stack.

TIA
Andy

PS yes we are asking the manufacturer if the switching can be done more
quickly. No answer as yet.

Andy <andy@symmetry.com.au> wrote:

Just a supporting note:

According to the radio supplier a slip connection will work. Is slip
supported in QNX 6.1.0 ?

No, but ppp is.

Thanks.
Andy

“Andy” <> andy@symmetry.com.au> > wrote in message
news:ch5li0$maf$> 1@inn.qnx.com> …
Hi all:

I’ve got a great tcp question. > :slight_smile:

There is a Windows ras server dialling to a number of remote QNX boxes.
The
link is via radio. The radios are designed for nasty environments and
changing propagation conditions, when a link is established it stays
established. However they are half duplex and NB they switch between tx
and
rx once per second! Yes even though the bit rate is 2400, for 1 second you
receive and then for 1 second you transmit. For tcpip this is a packet per
second throughput or packet and ack in under 2 seconds.

For the simple protocol that they used in the past, this was ok. Now they
want to use tcpip. We have setup the Windows and QNX sides to work
perfectly
with normal modems, however when we replace the modems with the radios no
joy. It nearly works, the link is established and ip addresses are
assigned
at both ends, its just that the very last part of the arbitration isn’t
completed and the QNX box keeps attempting to reset the QNX boxes default
route.

So my question is, is there a way to adjust the timings in the tcp stack
so
that a link this slow will work?

Which timing in particular are you talking about. The tcp level
socket timings are dynamic and based on round trip times and its
variance. Which ‘arbitration’ are you refering to?

I have noted a tcp_nodelay parameter for sockets that tries to send as
many
packets at once, but this seems to apply only to a socket. I need to do
this
for the whole stack.

TIA
Andy

PS yes we are asking the manufacturer if the switching can be done more
quickly. No answer as yet.

“Sean Boudreau” <seanb@qnx.com> wrote in message
news:ch73bp$pnv$1@inn.qnx.com

Andy <> andy@symmetry.com.au> > wrote:
Just a supporting note:

According to the radio supplier a slip connection will work. Is slip
supported in QNX 6.1.0 ?

No, but ppp is.

Thanks.
Andy

“Andy” <> andy@symmetry.com.au> > wrote in message
news:ch5li0$maf$> 1@inn.qnx.com> …
Hi all:

I’ve got a great tcp question. > :slight_smile:

There is a Windows ras server dialling to a number of remote QNX boxes.
The
link is via radio. The radios are designed for nasty environments and
changing propagation conditions, when a link is established it stays
established. However they are half duplex and NB they switch between tx
and
rx once per second! Yes even though the bit rate is 2400, for 1 second
you
receive and then for 1 second you transmit. For tcpip this is a packet
per
second throughput or packet and ack in under 2 seconds.

For the simple protocol that they used in the past, this was ok. Now
they
want to use tcpip. We have setup the Windows and QNX sides to work
perfectly
with normal modems, however when we replace the modems with the radios
no
joy. It nearly works, the link is established and ip addresses are
assigned
at both ends, its just that the very last part of the arbitration isn’t
completed and the QNX box keeps attempting to reset the QNX boxes
default
route.

So my question is, is there a way to adjust the timings in the tcp
stack
so
that a link this slow will work?

Which timing in particular are you talking about. The tcp level
socket timings are dynamic and based on round trip times and its
variance. Which ‘arbitration’ are you refering to?

I see from syslog : after pppd has agreed that the user and password are ok,
it then reports
“local ip: 10.1.1.1
remote ip: 10.1.1.22”
waits for approximately 5 seconds then repeats the previous lines. If I
repeatedly do a “netstat -rn” I see the default route appearing and
disappearing. It seems that pppd is stuck in the last phase of setting up
the link. I assume that because of the one second turnaround that something
is getting the info it needs too late timing out and restarting the setup.

Andy

I have noted a tcp_nodelay parameter for sockets that tries to send as
many
packets at once, but this seems to apply only to a socket. I need to do
this
for the whole stack.

TIA
Andy

PS yes we are asking the manufacturer if the switching can be done more
quickly. No answer as yet.

\

Andy <andy@symmetry.com.au> wrote:

Which timing in particular are you talking about. The tcp level
socket timings are dynamic and based on round trip times and its
variance. Which ‘arbitration’ are you refering to?

I see from syslog : after pppd has agreed that the user and password are ok,
it then reports
“local ip: 10.1.1.1
remote ip: 10.1.1.22”
waits for approximately 5 seconds then repeats the previous lines. If I
repeatedly do a “netstat -rn” I see the default route appearing and
disappearing. It seems that pppd is stuck in the last phase of setting up
the link. I assume that because of the one second turnaround that something
is getting the info it needs too late timing out and restarting the setup.

Try setting the ‘lcp-restart’ option:

pppd lcp-restart 10 …

-seanb

Can you pass “debug” to pppd and post the full log?

-xtang

Andy <andy@symmetry.com.au> wrote in message
news:ch7fel$3i1$1@inn.qnx.com

“Sean Boudreau” <> seanb@qnx.com> > wrote in message
news:ch73bp$pnv$> 1@inn.qnx.com> …
Andy <> andy@symmetry.com.au> > wrote:
Just a supporting note:

According to the radio supplier a slip connection will work. Is slip
supported in QNX 6.1.0 ?

No, but ppp is.

Thanks.
Andy

“Andy” <> andy@symmetry.com.au> > wrote in message
news:ch5li0$maf$> 1@inn.qnx.com> …
Hi all:

I’ve got a great tcp question. > :slight_smile:

There is a Windows ras server dialling to a number of remote QNX
boxes.
The
link is via radio. The radios are designed for nasty environments and
changing propagation conditions, when a link is established it stays
established. However they are half duplex and NB they switch between
tx
and
rx once per second! Yes even though the bit rate is 2400, for 1
second
you
receive and then for 1 second you transmit. For tcpip this is a
packet
per
second throughput or packet and ack in under 2 seconds.

For the simple protocol that they used in the past, this was ok. Now
they
want to use tcpip. We have setup the Windows and QNX sides to work
perfectly
with normal modems, however when we replace the modems with the
radios
no
joy. It nearly works, the link is established and ip addresses are
assigned
at both ends, its just that the very last part of the arbitration
isn’t
completed and the QNX box keeps attempting to reset the QNX boxes
default
route.

So my question is, is there a way to adjust the timings in the tcp
stack
so
that a link this slow will work?

Which timing in particular are you talking about. The tcp level
socket timings are dynamic and based on round trip times and its
variance. Which ‘arbitration’ are you refering to?

I see from syslog : after pppd has agreed that the user and password are
ok,
it then reports
“local ip: 10.1.1.1
remote ip: 10.1.1.22”
waits for approximately 5 seconds then repeats the previous lines. If I
repeatedly do a “netstat -rn” I see the default route appearing and
disappearing. It seems that pppd is stuck in the last phase of setting up
the link. I assume that because of the one second turnaround that
something
is getting the info it needs too late timing out and restarting the setup.

Andy


I have noted a tcp_nodelay parameter for sockets that tries to send
as
many
packets at once, but this seems to apply only to a socket. I need to
do
this
for the whole stack.

TIA
Andy

PS yes we are asking the manufacturer if the switching can be done
more
quickly. No answer as yet.



\