Rennie Allen <RAllen@csical.com> wrote:
The probable reason that delays decrease packet loss is that
the probability of a collision decreases. So isn’t what you
are asking for, to be able to decrease delays and packet loss
at the same time similar to my theological question?
Not wanting to start the deterministic network thread again, but the
answer to the question is to use a deterministic network media. With a
deterministic network, packet loss will not be inversly related to
packet interval.
I’ve been doing a bit of playing between two computers, and here
is what I found.
Environment
small LAN, with an other person have some internet traffic, but it
is behind a firewall. 2 machines each running RTP patch B, photon
2. 10Mbit network.
Machine 1: 350 PII, ne2000 clone sitting on the PcCard bus Machine
2: 233 P, Speedo/82557 sitting on the PCI bus
When I dump 1000, 1500 byte packets from
Machine 1 to 2, get virtually zero packet loss
Machine 2 to 1, get up to 30-50% packet loss.
Simple, ne2000 on a PcCard is probably going to move less data than
a 82557 on a PCI bus.
I figure you are saturating the net/machines durring your bursts.
I would suggest that you make your own protocol based on UDP packets.
I think you will have a hard time trying to figure out a “timeing”
that will work for all occasions and machine loads. Because of
course, the real time processes with have a higher priority, right?
Something along the lines of 5 packets out then wait for an ACK,
so you get the burst of the 5 packets then you will be slowed up
with the ACK. Of course TCP does that for you, it will burst, using
a sliding window approach where it will let itself get a few packets
ahead of the ACKs IIRC.
Anyway, if you pay attention to the return code from the send to,
the sending machine should not drop any packets itself, unless the
PHY is going bad.
It’s not pretty but here is what I have for a sending loop:
size=1500;
for (ctr=0; ctr<1000; ++ctr) {
*(unsigned long *)data=ctr;
do {
if ((out=sendto(sock, data, size, 0,
(struct sockaddr *)&name, sizeof(name))) < 0) {
if (errno=ENOSPC) continue;
perror(“sending datagram message”);
break;
}
} while (out<size);
}
close(sock);
YMMV
Anyway, if the DATA must get there, then you are going to have to
use something that gives you reliability. Whether it is a roll your
own, that you can tune. Or standard TCP, unless the bandwidth is
low enough that you are not going to get any overruns anywhere, or
you can stand loosing packets, you are not going to accomplish what
you need.
Tom
– Thomas Emberson <Thomas@QNX.com>
The TCP packet header is larger, and