Traffic Shaping

Hi all,

It's been a few days now since i installed my first m0n0 box.
I'm using VoIP services along with P2P (eDonkey/eMule) on a 512/128 DSL connection, several speed test reported that this is actually 586/157... .

For VoIP needs i have a Linsys PAP2 adapter confirured in the static DHCP with IP 172.16.0.4. The P2P machine, is at 172.16.0.2.

In order to get good audio with no gaps my VoIP adapter needs at least 10kbytes/s in each direction.

Using Magic Shaper and some tweaking i finally managed to get crystal clear audio on my VoIP calls. I created a queue with weight 100 and th eonly thing that gets in this queue is my VoIP adapter's traffic. It is my understanding that a queue weghted 100 will have 2 times mores bandwidth than a queue weighted 50 and 100 times more bandwidth than a queue weighted 1.

While i am satisfied with audio, i'm still experiencing latency in my calls. The hear the person with no latency at all, but in the other direction i sometimes have about 1s latency i.e.: when i start speaking it will last 1s until the other person can ear what i'm saying....

When P2P is not running i have no latency at all !


Can someone tell me what i might be missing or doing wrong ?


Thanks a lot !

What is your CPU usage graph looking like while both are going on?  If you're using a weak machine as a monowall, maybe it's having a hard time keeping up?  The other option you could go with would be 2 separate pipes for in and out just for your VOIP, and make the pipe 10k each way; that would break off 10kbps from everything else all the time, but it would make sure your VOIP always has what i needs with no delay...worth a shot, anyway

Thank you for you reply !

I'm running m0nowall on a refurbished thin client which is powered by a Via C3 530Mhz CPU and 256MB Ram, i assume this is powerful enough  . When making calls the CPU load does not exceed 3%.
Today i finally resolved my issue.... In fact, the online speed test i was using seemed to measure the IP speed and then added some overhead to get the ATM speed. I do not care about the ATM speed, i want to know what is usable for me i.e.: IP speed. The speed reported by this speed test almost matches the ATM speed reported by my modem.
Long story short, i made some experiments and found out that if i reduce my upload pipe to 80kbps the VoIP calls have no or very little latency. And during calls the P2P upload speeds drops to nearly 0kbps (VoIP needs about 80kbps).
So i experimented each time increasing the value of the pipe. Finally, guess what ? having my pipe set up to 128kbps worked fine ! I have now almost all of my bandwidth when not making VoIP calls !
I think i'll change my modem for one allowing me to do PPPoA in a half bridged mode (i.e.: the modem takes care of all the PPP stuff and exposes the public IP on its WAN port) maybe i could then get rid of the PPPoE overhead and get the 160kbps upload !

I think setting the correct upload speed is very important. I guess, m0n0wall tries to send packets as fast as possible until it reaches the limit specified into the pipe. If the limit specified in the pipe is greater than your actual bandwidth packets get queud in the modem or somewhere else thus, P2P packets reach the modem and in there are treated the same way as VoIP packets..... This is my interpretation of my personal experiments, correct me if i'm wrong

I think setting the correct upload speed is very important. I guess, m0n0wall tries to send packets as fast as possible until it reaches the limit specified into the pipe. If the limit specified in the pipe is greater than your actual bandwidth packets get queud in the modem or somewhere else

Correct. Most ISPs allow you a sustained speed and then a burst speed. The latter is often what they sell you. I had a connection with a 1024 upload and as soon as I set my pipe to 1001 with heavy uploads, latency. Set it to 1000 and no more latency. You want the queue short and in your control (at the router) rather than long and out of your control (at the ISP).

db

You want the queue short and in your control (at the router) rather than long and out of your control (at the ISP).

db

This is pretty well summarized