Is it really possible (and makes sense) to make QNet using a half
duplex
serial radio modem?
Seems that Net.fd allows that (with some programming),
but what about efficiency? I feel, there’d be a lot of switching
to transmit and receive state of the radio unit for Qnet data passing.
Any input is welcome.
Thanks
Oleg
In QNX4 Net.fd over a perfectly reliable full-duplex link is slow at best.
Many packets will err-out simple because they took too long to get across
the link.
The slower the link is and the more unreliable the link is the more I would
say, don’t use it.
Net.fd was fun to play with for a while but it doesn’t have any real
application in the real world.
This is of course my own opinion.
–
Bill Caroselli – 1(626) 824-7983
Q-TPS Consulting
QTPS@EarthLink.net
“Oleg A. Khamayko” <olegax@mail.ru> wrote in message
news:3C5667BA.CE94CFC8@mail.ru…
Is it really possible (and makes sense) to make QNet using a half
duplex
serial radio modem?Seems that Net.fd allows that (with some programming),
but what about efficiency? I feel, there’d be a lot of switching
to transmit and receive state of the radio unit for Qnet data passing.Any input is welcome.
Thanks
Oleg
Alex Cellarius wrote:
On Tue, 29 Jan 2002 08:42:22 -0800, “Bill Caroselli” <> qtps@earthlink.net> > wrote:
In QNX4 Net.fd over a perfectly reliable full-duplex link is slow at best.
Many packets will err-out simple because they took too long to get across
the link.The slower the link is and the more unreliable the link is the more I would
say, don’t use it.Net.fd was fun to play with for a while but it doesn’t have any real
application in the real world.
Regrettably I have to agree, and I only ever played with it with
a null modem (ie 100% reliable) link.
I concur also. For unreliable, slow links use TCP/IP. Using QNX native
networking for this type of link is as much a mis-application as using
TCP/IP on deterministic local area networks for distributed real-time
control.
On Tue, 29 Jan 2002 08:42:22 -0800, “Bill Caroselli” <qtps@earthlink.net> wrote:
In QNX4 Net.fd over a perfectly reliable full-duplex link is slow at best.
Many packets will err-out simple because they took too long to get across
the link.The slower the link is and the more unreliable the link is the more I would
say, don’t use it.Net.fd was fun to play with for a while but it doesn’t have any real
application in the real world.
Regrettably I have to agree, and I only ever played with it with
a null modem (ie 100% reliable) link.
Rennie Allen wrote:
Alex Cellarius wrote:
On Tue, 29 Jan 2002 08:42:22 -0800, “Bill Caroselli” <> qtps@earthlink.net> > wrote:
In QNX4 Net.fd over a perfectly reliable full-duplex link is slow at best.
Many packets will err-out simple because they took too long to get across
the link.The slower the link is and the more unreliable the link is the more I would
say, don’t use it.Net.fd was fun to play with for a while but it doesn’t have any real
application in the real world.
Regrettably I have to agree, and I only ever played with it with
a null modem (ie 100% reliable) link.I concur also. For unreliable, slow links use TCP/IP. Using QNX native
networking for this type of link is as much a mis-application as using
TCP/IP on deterministic local area networks for distributed real-time
control.
Thanks, I see.
A question about the TCI/IP for QNX4. Is it possible to use TCP/IP
stack on
half duplex radio channels? [The key point is that there must be
switching to trasmit/receive state of the radio unit].
Or we are to write our own I/O manager for the such media?
Oleg
Oleg A. Khamayko wrote:
Rennie Allen wrote:
Thanks, I see.
A question about the TCI/IP for QNX4. Is it possible to use TCP/IP
stack on
half duplex radio channels? [The key point is that there must be
switching to trasmit/receive state of the radio unit].Or we are to write our own I/O manager for the such media?
Yes, either write your own I/O manager or perhaps create a Dev driver.
Then simply run ppp or slip on your new device. I think that creating a
new Dev driver might be easier (depending on exactly what your hardware
looks like), since it already has all the functionality required by ppp
on the resource manager side.
The problem is similar in concept to the RS-485 FAQ.
Rennie
Rennie Allen wrote:
Oleg A. Khamayko wrote:
Rennie Allen wrote:
Thanks, I see.
A question about the TCI/IP for QNX4. Is it possible to use TCP/IP
stack on
half duplex radio channels? [The key point is that there must be
switching to trasmit/receive state of the radio unit].Or we are to write our own I/O manager for the such media?
Yes, either write your own I/O manager or perhaps create a Dev driver.
Then simply run ppp or slip on your new device. I think that creating a
new Dev driver might be easier (depending on exactly what your hardware
looks like), since it already has all the functionality required by ppp
on the resource manager side.
Thanks. How do you think what TCP/IP throughout could be achieved
on such lines? Is about 1/5 of bandwidth feels to be a good number?
Oleg