| To: | Stephen Hemminger <shemminger@xxxxxxxx> |
|---|---|
| Subject: | Re: [PATCH 2.6] update to network emulation QOS scheduler |
| From: | jamal <hadi@xxxxxxxxxx> |
| Date: | 07 Jul 2004 14:57:48 -0400 |
| Cc: | "David S. Miller" <davem@xxxxxxxxxx>, Catalin BOIE <util@xxxxxxxxxxxxxxx>, netdev@xxxxxxxxxxx, lartc@xxxxxxxxxxxxxxx |
| In-reply-to: | <20040707111055.32ebb25b@dell_ss3.pdx.osdl.net> |
| Organization: | jamalopolis |
| References: | <20040701113312.43cfe6c5@dell_ss3.pdx.osdl.net> <20040702134437.5891e998@dell_ss3.pdx.osdl.net> <1088824432.1043.271.camel@jzny.localdomain> <20040707111055.32ebb25b@dell_ss3.pdx.osdl.net> |
| Reply-to: | hadi@xxxxxxxxxx |
| Sender: | netdev-bounce@xxxxxxxxxxx |
I seem to have hit the jackpot - all my emails to netdev are showing up and on time too. On Wed, 2004-07-07 at 14:10, Stephen Hemminger wrote: > Ok, I'll bite how would you do: > > Rate limit packet egress on a ethernet device (eth0) so it looks like a slow > DSL link (25 Kbps) > by not dropping packets but by pacing the data. Doesnt TBF work? rate 25kbit burst 90k should probably do it. Maybe i misunderstood the question. You may be able to avoid dropping but dont think you can guarantee it simply because you have finite buffers. At some point you will congest that queue and packets will be dropped; and if you dont limit your queue buffer size, sooner than later you are bound to hog all the system memory. Having said that, i have never seen a good arguement for why pacing traffic vs dropping to initiate a slowdown is better than the other. So in that case, a policer/meter should suffice. cheers, jamal |
| Previous by Date: | Re: [PATCH 2.6] update to network emulation QOS scheduler, jamal |
|---|---|
| Next by Date: | [PATCH] net/ipv4/ipmr.c fixes, OGAWA Hirofumi |
| Previous by Thread: | Re: [PATCH 2.6] update to network emulation QOS scheduler, Stephen Hemminger |
| Next by Thread: | Re: [PATCH 2.6] update to network emulation QOS scheduler, Stephen Hemminger |
| Indexes: | [Date] [Thread] [Top] [All Lists] |