Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

100 mbnic problem

0 views
Skip to first unread message

Nate

unread,
Jul 13, 1998, 3:00:00 AM7/13/98
to
I am writing a streaming server for a voice over IP application. I have
optimized it over and over again till I am blue in the face. I could only
get 70 people on the stream before it would simple stop working. I thought
it was my code. But, I researched this and found that each Winsock stack
has 1 buffer to work with!!! Every application works from this one buffer
for sending and receiving. When my user count got to +70, I would have 70
packets in the buffer and then there was no more room to receive packets or
put any more in to send. Then the other sending application attached would
lose its connection because it was not getting anything back from the
server! This bit rate was right around 1 megabit/sec. Why in the world do
we have 10 or 100 megabit/sec nics if Winsock can not support them?????
Does anyone have any suggestions for me as to how I can get more buffer
space for winsock? Please help.

Just remove the JUNK to mail me!
na...@JUNKmktaccess.com

madhu

unread,
Jul 15, 1998, 3:00:00 AM7/15/98
to
Hello,
Have you tried increasing the send and receive buffers using
setsockopt().
May be it might helpp to some extent
madhu


_________________________________________________________________

B.Madhusudhan SISL Bangalore.Tel:(off) +91-080-8521122 ext - 4294
Mailto:ma...@blr.sni.de

Nate

unread,
Jul 21, 1998, 3:00:00 AM7/21/98
to
I thought I put that in the message. I have asked winsock for as much
buffer as I can get on send and receive. ask for 9999999. It usually gives
me 65280. This helps, but does not get you anywhere near 10 or 100 mBits.
madhu wrote in message <35ACD046...@blr.sni.de>...

Russell Bornschlegel

unread,
Jul 21, 1998, 3:00:00 AM7/21/98
to Nate
Nate wrote:
> [...] When my user count got to +70, I would have 70

> packets in the buffer and then there was no more room to receive packets or
> put any more in to send. Then the other sending application attached would
> lose its connection because it was not getting anything back from the
> server! This bit rate was right around 1 megabit/sec. Why in the world do
> we have 10 or 100 megabit/sec nics if Winsock can not support them?????

10 or 100 mb/sec Ethernet describes the signalling rate supported by
the NIC, not the data transfer rate for the whole system. If you have
moe than one machine on the network segment, their transmissions will
occasionally "collide" - both will try to send at once on the same
wire. In that case, each waits a (different) semi-random amount of time
and then tries again, hoping to miss the other machine's re-send.

So, if one machine is sending at 9mb/sec on a 10mb Ethernet, the odds
are very high that any other machine that tries to send will cause a
packet collision, which will cause both machines to re-send, which will
pretty much lead to a "packet storm" and total congestion in a very
short
time. Sustained rates of 2-3 mb/sec over a 10mb/sec Ethernet is about as
good as you'll get, so Microsoft doesn't bother tuning their TCP/IP
stacks
for anything faster.

On a 100mb/sec Ethernet, you can put 10 times as many machines on
without any more congestion problem (*that's* why we have 100mb NICs),
but a single machine still won't be able to put out more than that
3mb/sec
or so.

This is where the Linux and FreeBSD advocates usually step in and say
that their chosen OSs are 10 times faster than Windows. In deference
to the fact that this is a winsock group, I'll say that *if* switching
platforms is an option for you, it might pay off; Linux and BSD are
known for their very fast TCP/IP implementations; they can make more
use of that 100mb/sec Ethernet or OC3 connection than Windows can.

Now, as for your application, you don't say whether your users
are on your Ethernet LAN or off-site (like on the other end of a T1),
and you don't say whether you're using UDP (SOCK_DGRAM) or TCP
(SOCK_STREAM), nor whether your LAN is 10mb or 100mb, so forgive me
if some of the following is irrelevant:

If you're using TCP on a LAN, the acknowledgement overhead is taking up
a little bandwidth.

If your clients are sending data back, that's taking up LAN bandwidth
too.

If you're using UDP on a LAN, and sending the exact same data stream to
each client/user, you might consider sending to the local broadcast
address (255.255.255.255). This makes your outbound data rate
independent
of the number of LAN clients involved.

If you're sending off the LAN, note that a T1 signalling rate is
about 1.5mb/sec. If you're on a T3, of course, that's not the problem
here.

If you're pushing everything out a single UDP/datagram socket, try
creating multiple sockets and allocating 30 clients to each socket.

Hope some of this helps...

-Russell Bornschlegel

0 new messages