RE: ADSL Bandwidth Monitoring
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of RW Sent: Sunday, September 09, 2007 2:35 PM To: freebsd-questions@freebsd.org Subject: Re: ADSL Bandwidth Monitoring On Sat, 8 Sep 2007 23:16:35 -0700 Ted Mittelstaedt [EMAIL PROTECTED] wrote: ... However, the thing that most people (who don't work at telcos) do not understand is that the telcos found very quickly that they cannot put contention into an ATM network comprised of a DSL atm circuits for a very simple reason. ... SO, the cost of discarding a single 56 byte ATM cell means the ATM cloud will have to get another 1400 bytes of data retransmitted through it. It doesen't take a rocket scientist to see that introducing contention into an ATM circuit carrying a DSL circuit will cause a massive increase in traffic in the switch, and wipe out any gains from contention. I don't know much about DSLAMS, but ATM switches have been able to drop whole AAL5 frames for a long time. Do DSLAMS really not have EPD/PPD? Why would they need it? The DSLAM doesen't need to control the traffic with ATM policing. It has control of the DSL circuit, remember. The modems aren't allowed to train at any old speed. They can only train up to the circuit speed the DSLAM port is configured to let them so the ATM circuit in the DSLAM is never going to see more traffic than what the port was contracted at. And, in any case, most of the DSL in the United States is asymmectrical - the customer receives far more bandwidth than they can transmit. Most of the RADSL modems out there in the US have chipsets that max at 7MB down and 1MB up. So, the DSLAM is going to be connected to an upstream link that can service the traffic coming FROM the upstream TO the DSLAM and TO the remote customers. When the DSLAM gets the traffic it's already been rate-limited. The only time the DSLAM would possibly need to rate-limit traffic is received traffic FROM the customer TO the upstream - and it is going to very likely be using an upstream pipe that is symmectrical, with gobs of available traffic - so a scenario where the DSLAM would need to rate limit traffic sent into the upstream pipe is difficult to imagine. It's also difficult to imagine that a telco would use ATM policing on the ATM switch that the ISP is connected to. That switch isn't going to see the rest of the telco's ATM network, and the ISP is going to be traffic limiting the VC's they are sending into the telco. Remember the telcos charge the ISP's for the privilege of interconnecting, and their charges are based on bandwidth. If an ISP contracts with a telco for, say 10MB of bandwidth, and the Telco starts policing at the ATM switch the ISP is connected to that limits it down to 5MB, then I would imagine it would be quite quick that the ISP's lawyers would be suing the telco. Hardly the way for a telco to entice the ISP to buy even more bandwidth on their DSL feed. To use EPD/PPD to police aal5 you would have to do it in the central ATM switch that all your remote DSLAMS are plugged into and that is also plugged into all the ATM switches that are feeding your ISP customers. But then the question becomes - how are you going to do it? Set fixed policing on all the DSL pvc's that are going through the ATM switch? To what end? If your going to fix-limit it, you might as well limit the individual DSLAM port that the customer is using and then free up more bandwidth that your going to burn up transferring the cells from the ISP through the first hop switch and into your main master atm switch. No you would have to dynamically limit it somehow. While I'm sure that these kinds of schemes exist, it seems to me just as easy to just buy a bigger ATM switch. However the contention is done, it definitely happens in the UK. Well, they drive on the wrong side of the road there too. ;-) Keep in mind I am not saying it is impossible for a telco to introduce contention into a DSL network. It is just a motive thing. Think of how their DSL network is put together and you can see that if you police in a central switch your going to be chewing up bandwidth in the rest of your network, and if you police at the fringes your going to have a lot of coordination issues to handle. To me the incentive doesen't seem to exist at the Telco to do it. It seems much more incentive exists at the ISP to do it. Ted ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: ADSL Bandwidth Monitoring
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Joao Barros Sent: Saturday, September 08, 2007 7:33 PM To: Ted Mittelstaedt Cc: freebsd-questions@freebsd.org Subject: Re: ADSL Bandwidth Monitoring On 9/8/07, Ted Mittelstaedt [EMAIL PROTECTED] wrote: -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Amitabh Kant Sent: Saturday, September 08, 2007 12:25 PM To: Bahman M. Cc: freebsd-questions@freebsd.org Subject: Re: ADSL Bandwidth Monitoring On 9/8/07, Bahman M. [EMAIL PROTECTED] wrote: I tested the connection by downloading 2~3 files simultaneously and used 'bmon' as Mel suggested in another reply (thanks to him). As I'd already guessed the RX don't get bigger than 30~40% of the expected bandwidth. I performed the test with some other files and there was no difference. Thanks, Bahman The bandwidth being advertised by your ISP would be the maximum thoughput allowed on your DSL lines with multiple DSL users sharing the same bandwidth, something that is generally known as contention ratio. Rubbish. I work for an ISP and this is nonsense. DSL is not a shared medium until it gets to the ISP and the ISP should be able to handle full rate circuits internally. From the customer to the DSLAM it's a copper pair. No contention on that. If the DSLAM is far from the ISP backbone you have a shared connection. That's where contention is applied. No, sorry. There's not that many different types of DSL that are deployed simply because there's only a handful of companies out there that manufacture DSL chipsets, and DSLAMS. Virtually all DSLAMS that are out there use an ATM cell circuit from the DSLAM to the ISP. Fujitsu for a while was making frame-relay based DSLAMS but telcos finally stopped buying them and nobody is using them now. The ATM connection uses either variable speed bitrate or unspecified bitrate. Not committed bitrate that is used for voice circuits through an ATM network. The reason for this is that all telcos these days use ATM switches to carry voice calls - ATM was a standard dreamed up by the telcos specifically for carrying phone calls. When DSL was first dreamed up it was thought that to save money on backend fiber costs that the telcos could use smaller pipes and introduce contention. That is why ubr and vbr encapsulations were selected instead of cbr. However, the thing that most people (who don't work at telcos) do not understand is that the telcos found very quickly that they cannot put contention into an ATM network comprised of a DSL atm circuits for a very simple reason. The ATM cell is a fixed 56k bytes. The majority of Ethernet packets once a TCP stream gets going and has adjusted it's sliding windows are close to 1400 bytes long. Now, imagine what happens to an ATM cloud when you program the ATM switch that the cloud resides in to introduce contention into the cloud. The ATM switch does this by dropping ATM cells in all the ubr and vbr ATM circuits that traverse the switch. As a result, you start missing 56 byte packets in your ATM stream that the DSL is riding on. If the sender and receiver were using 56 byte MTU's this would be no problem. A missing ATM cell would cause a retransmit of the TCP/IP packet and would be handled by the TCP protocol. But since the sender are receiver are using 1500 byte MTU's and the TCP packets are almost that large, what ends up happening is that even a small amount of contention in the ATM cloud will cause almost every TCP packet to have bits missing in it - ie:, to arrive with an invalid CRC and be discarded. Worse, since the entire packet is missing the sender and receiver's TCP stack has to retransmit the packet, loading the ATM cloud down even more. SO, the cost of discarding a single 56 byte ATM cell means the ATM cloud will have to get another 1400 bytes of data retransmitted through it. It doesen't take a rocket scientist to see that introducing contention into an ATM circuit carrying a DSL circuit will cause a massive increase in traffic in the switch, and wipe out any gains from contention. Furthermore, your customers will start dropping TCP connections without reason, when the stacks get long series of 1400 byte packets one after another that are corrupted. And then calling you and bitching and wasting your tech support time. When the Telcos found this out they gave up on that idea. DSL circuits today that traverse any ATM cloud -as virtually all of them do since virtually all telcos use ATM backbones in their DSL networks - cannot have contention introduced into them by the Telco. Even the practice of delaying ATM cells causes the same problems because you cannot introduce enough delay for the packet reassembly process in the DSL modem and the DSLAM to actually show latency on the entire packet, without damaging it. If for example
Re: ADSL Bandwidth Monitoring
Hi Bahman, Bahman M. wrote: Hi all, I have an ADSL connection at home. When I'm _uploading_ files the whole upload bandwidth is consumed; so far so good. But when _downloading_ no more than 30~40% of download bandwidth is consumed. The guys in the ISP say they've granted me the requested bandwidth but this is not what I see in action. How may I know the real bandwidth limits of my connection? Any tool or trick? Or maybe I'm misunderstanding something about ADSL bandwidth? First of all, I would demand that the ISP where you are acquiring your ADSL bandwidth provide you with your bandwidth utilization MRTG or RRD graphs. It is the responsibility of every ISP to provide their clients the bandwidth usage graphs no matter how big or small they are! Other than that, make sure that your uplink is not 100% utilized while performing download tests. Other factors affecting your downlink could be your bandwidth might be shared or burstable and not dedicated. Have you tried performing downlink tests in the wee hours when there could be almost nobody contenting for bandwidth if your bandwidth is burstable? For basic upload and download tests, you can visit the following URL: http://www.speakeasy.net/speedtest/ But still, your first priority would be to get the bandwidth utilization graphs from your ISP. Thanking you... TIA, Bahman ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED] -- With best regards and good wishes, Yours sincerely, Tek Bahadur Limbu System Administrator (TAG/TDG Group) Jwl Systems Department Worldlink Communications Pvt. Ltd. Jawalakhel, Nepal http://www.wlink.com.np ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ADSL Bandwidth Monitoring
Thank you all for the information and the hints; very helpful. At least, now I've got a clue. Bahman ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ADSL Bandwidth Monitoring
On Sat, 8 Sep 2007 23:16:35 -0700 Ted Mittelstaedt [EMAIL PROTECTED] wrote: ... However, the thing that most people (who don't work at telcos) do not understand is that the telcos found very quickly that they cannot put contention into an ATM network comprised of a DSL atm circuits for a very simple reason. ... SO, the cost of discarding a single 56 byte ATM cell means the ATM cloud will have to get another 1400 bytes of data retransmitted through it. It doesen't take a rocket scientist to see that introducing contention into an ATM circuit carrying a DSL circuit will cause a massive increase in traffic in the switch, and wipe out any gains from contention. I don't know much about DSLAMS, but ATM switches have been able to drop whole AAL5 frames for a long time. Do DSLAMS really not have EPD/PPD? However the contention is done, it definitely happens in the UK. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ADSL Bandwidth Monitoring
On Sat, 8 Sep 2007 15:05:03 -0700
Ted Mittelstaedt [EMAIL PROTECTED] wrote:
Get a personal website from the ISP
Definitely - testing from anywhere else than somewhere in your ISP's network
will add to the equation all the bandwidth-affecting-factors to/from the
*other* network / hosts. Once you've proven your point within your ISP's
network, you can move on to discuss whether your connection to the outer world
is worse than expected.
Upload a file to the personal webserver
I would suggest a large file - small files will not be good enough for
measuring your download speed. at least 20 Mb.
Download the file from the personal webserver.
If the bandwidth isn't what it's supposed to be, then
have the ISP call the local telephone company and have
that company check to see that your modem is training at
the correct rate.
adsl modems will train at lower speeds if there is
trouble with the phone line.
indeed, issues with your phone socket where u connect your modem to + overall
quality of the line will make a big difference. I drop from 3.5 Mb / 900K from
on socket in my place to 2.8 / 600 in another. Same phone line ,different
cable/socket, same modem. (that's the speed reported by the modem itself).
BTW, what is the speed reported by the modem itself? most modems have a webpage
to get , at least, this information from - even if running in bridged mode.
Check the manufacturers website for information on how to do this.
B
_
{Beto|Norberto|Numard} Meijome
He has the attention span of a lightning bolt.
Robert Redford
I speak for myself, not my employer. Contents may be hot. Slippery when wet.
Reading disclaimers makes you go blind. Writing them is worse. You have been
Warned.
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ADSL Bandwidth Monitoring
On Saturday 08 September 2007 16:16:08 Bahman M. wrote: How may I know the real bandwidth limits of my connection? Any tool or trick? Or maybe I'm misunderstanding something about ADSL bandwidth? net/bmon is a good tool to see the bandwidth of your local interfaces. Other then that, bandwidth is the sum of all factors between there and here. -- Mel ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ADSL Bandwidth Monitoring
On 9/8/07, Bahman M. [EMAIL PROTECTED] wrote: Hi all, I have an ADSL connection at home. When I'm _uploading_ files the whole upload bandwidth is consumed; so far so good. But when _downloading_ no more than 30~40% of download bandwidth is consumed. The guys in the ISP say they've granted me the requested bandwidth but this is not what I see in action. How may I know the real bandwidth limits of my connection? Any tool or trick? Or maybe I'm misunderstanding something about ADSL bandwidth? First of all you have to take into account that with an ADSL connection, I'm guessing PPPoE, you have overhead due to protocol tunnelling. Next you must verify that you don't max out your upload while testing download speed. From my tests, up to 90% upload bandwidth usage is safe and shows no impact on download performance. And for last, use multiple download sources as only one may not be enough. Find http or ftp mirrors close to you (on your ISP for ex) and start downloading multiple ISOs for example. Note: Make sure the device taking care of the PPPoE connection is powerful enough to support your bandwidth. For example, I still have a Linksys WRT54GL as router and I can easily see 100% cpu usage and load 1 and thus I can't use my max contracted bandwidth. Use the modem or a powerful enough machine running FreeBSD of course :) -- Joao Barros ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ADSL Bandwidth Monitoring
Joao Barros wrote: On 9/8/07, Bahman M. [EMAIL PROTECTED] wrote: Hi all, I have an ADSL connection at home. When I'm _uploading_ files the whole upload bandwidth is consumed; so far so good. But when _downloading_ no more than 30~40% of download bandwidth is consumed. The guys in the ISP say they've granted me the requested bandwidth but this is not what I see in action. How may I know the real bandwidth limits of my connection? Any tool or trick? Or maybe I'm misunderstanding something about ADSL bandwidth? First of all you have to take into account that with an ADSL connection, I'm guessing PPPoE, you have overhead due to protocol tunnelling. The connection is a simple ethernet connection (sorry, I don't know the exact technical name) which requires no authentication and setup (I have a valid static IP address). On a fresh system, I just need to specify gateway IP and my own machine's and plug the cable in and it starts working Next you must verify that you don't max out your upload while testing download speed. From my tests, up to 90% upload bandwidth usage is safe and shows no impact on download performance. Tested while not uploading and the results were the same. And for last, use multiple download sources as only one may not be enough. Find http or ftp mirrors close to you (on your ISP for ex) and start downloading multiple ISOs for example. I tested the connection by downloading 2~3 files simultaneously and used 'bmon' as Mel suggested in another reply (thanks to him). As I'd already guessed the RX don't get bigger than 30~40% of the expected bandwidth. I performed the test with some other files and there was no difference. Note: Make sure the device taking care of the PPPoE connection is powerful enough to support your bandwidth. For example, I still have a Linksys WRT54GL as router and I can easily see 100% cpu usage and load 1 and thus I can't use my max contracted bandwidth. Use the modem or a powerful enough machine running FreeBSD of course :) Don't worry about that! My connection is such slow that even the primitive NICs and CPUs would handle it :-) Thanks, Bahman ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ADSL Bandwidth Monitoring
On 9/8/07, Bahman M. [EMAIL PROTECTED] wrote: I tested the connection by downloading 2~3 files simultaneously and used 'bmon' as Mel suggested in another reply (thanks to him). As I'd already guessed the RX don't get bigger than 30~40% of the expected bandwidth. I performed the test with some other files and there was no difference. Thanks, Bahman The bandwidth being advertised by your ISP would be the maximum thoughput allowed on your DSL lines with multiple DSL users sharing the same bandwidth, something that is generally known as contention ratio. See this link: http://en.wikipedia.org/wiki/Contention_ratio Amitabh ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ADSL Bandwidth Monitoring
Amitabh Kant wrote: On 9/8/07, Bahman M. [EMAIL PROTECTED] wrote: I tested the connection by downloading 2~3 files simultaneously and used 'bmon' as Mel suggested in another reply (thanks to him). As I'd already guessed the RX don't get bigger than 30~40% of the expected bandwidth. I performed the test with some other files and there was no difference. Thanks, Bahman The bandwidth being advertised by your ISP would be the maximum thoughput allowed on your DSL lines with multiple DSL users sharing the same bandwidth, something that is generally known as contention ratio. See this link: http://en.wikipedia.org/wiki/Contention_ratio Amitabh But you should be able to hit the advertised bandwidth. To the best of my knowledge, DSL itself is NOT a shared medium. It is a point-to- point technology from your premise to the Central Office. The bandwidth *behind* the CO may be shared, but should be so large as to not be a bottleneck. My provider (Speakeasy) advertises 1.5/384 ADSL for my circuit and that is *exactly* what I get whether moving a single file or multiple files simultaneously. There are only two reasons I can think of that would prevent you from hitting full advertised bandwidth: 1) You are too far away from the CO to hold up the circuit a full speed. Most DSL bridges/routers are adaptive and will downshift to a speed where the error rate is reduced to an acceptable level. Even if you are not far away from the CO, you will also see this if the copper pair is noisy for some other reason: bad grounding, bad splicing, old wire, etc. 2) Your premise wiring is hosed. Home telephone wiring is typically utter crap for data, even on newer homes. A new run of Cat 3 cable directly from the Network Interface box on the side of the building to the jack where the DSL bridge plugs in can do wonders. Also make sure that the cable from the bridge to that jack is good - I just had one go bad and wreak havoc for a while in my office. HTH, -- Tim Daneliuk [EMAIL PROTECTED] PGP Key: http://www.tundraware.com/PGP/ ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ADSL Bandwidth Monitoring
On Sat, 08 Sep 2007 15:27:38 -0500 Tim Daneliuk [EMAIL PROTECTED] wrote: Amitabh Kant wrote: On 9/8/07, Bahman M. [EMAIL PROTECTED] wrote: I tested the connection by downloading 2~3 files simultaneously and used 'bmon' as Mel suggested in another reply (thanks to him). As I'd already guessed the RX don't get bigger than 30~40% of the expected bandwidth. I performed the test with some other files and there was no difference. Thanks, Bahman The bandwidth being advertised by your ISP would be the maximum thoughput allowed on your DSL lines with multiple DSL users sharing the same bandwidth, something that is generally known as contention ratio. See this link: http://en.wikipedia.org/wiki/Contention_ratio Amitabh But you should be able to hit the advertised bandwidth. To the best of my knowledge, DSL itself is NOT a shared medium. It is a point-to- point technology from your premise to the Central Office. The bandwidth *behind* the CO may be shared, but should be so large as to not be a bottleneck. It depends on your circumstances. Some people are constrained by contention ratio some aren't. Some ISPs offer a better ratio for a more expensive accounts. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ADSL Bandwidth Monitoring
RW wrote: On Sat, 08 Sep 2007 15:27:38 -0500 Tim Daneliuk [EMAIL PROTECTED] wrote: Amitabh Kant wrote: On 9/8/07, Bahman M. [EMAIL PROTECTED] wrote: I tested the connection by downloading 2~3 files simultaneously and used 'bmon' as Mel suggested in another reply (thanks to him). As I'd already guessed the RX don't get bigger than 30~40% of the expected bandwidth. I performed the test with some other files and there was no difference. Thanks, Bahman The bandwidth being advertised by your ISP would be the maximum thoughput allowed on your DSL lines with multiple DSL users sharing the same bandwidth, something that is generally known as contention ratio. See this link: http://en.wikipedia.org/wiki/Contention_ratio Amitabh But you should be able to hit the advertised bandwidth. To the best of my knowledge, DSL itself is NOT a shared medium. It is a point-to- point technology from your premise to the Central Office. The bandwidth *behind* the CO may be shared, but should be so large as to not be a bottleneck. It depends on your circumstances. Some people are constrained by contention ratio some aren't. Some ISPs offer a better ratio for a more expensive accounts. I don't understand this. If the actual DSL circuit is point-to-point - i.e., not shared between the premise and the DSLAM in the CO, just exactly *where* is the contention occuring? I would think (and could be wrong) that the only other place would be in the bandwidth behind the DSLAM - the actual phone network. But this is typically very, very high capacity stuff, at least here in the US, and I sort of doubt it couldn't deliver the stated bandwidth. Not arguing here, just wondering... -- Tim Daneliuk [EMAIL PROTECTED] PGP Key: http://www.tundraware.com/PGP/ ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: ADSL Bandwidth Monitoring
Get a personal website from the ISP Upload a file to the personal webserver Download the file from the personal webserver. If the bandwidth isn't what it's supposed to be, then have the ISP call the local telephone company and have that company check to see that your modem is training at the correct rate. adsl modems will train at lower speeds if there is trouble with the phone line. Ted -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Bahman M. Sent: Saturday, September 08, 2007 7:16 AM To: freebsd-questions@freebsd.org Subject: ADSL Bandwidth Monitoring Hi all, I have an ADSL connection at home. When I'm _uploading_ files the whole upload bandwidth is consumed; so far so good. But when _downloading_ no more than 30~40% of download bandwidth is consumed. The guys in the ISP say they've granted me the requested bandwidth but this is not what I see in action. How may I know the real bandwidth limits of my connection? Any tool or trick? Or maybe I'm misunderstanding something about ADSL bandwidth? TIA, Bahman ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: ADSL Bandwidth Monitoring
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Amitabh Kant Sent: Saturday, September 08, 2007 12:25 PM To: Bahman M. Cc: freebsd-questions@freebsd.org Subject: Re: ADSL Bandwidth Monitoring On 9/8/07, Bahman M. [EMAIL PROTECTED] wrote: I tested the connection by downloading 2~3 files simultaneously and used 'bmon' as Mel suggested in another reply (thanks to him). As I'd already guessed the RX don't get bigger than 30~40% of the expected bandwidth. I performed the test with some other files and there was no difference. Thanks, Bahman The bandwidth being advertised by your ISP would be the maximum thoughput allowed on your DSL lines with multiple DSL users sharing the same bandwidth, something that is generally known as contention ratio. Rubbish. I work for an ISP and this is nonsense. DSL is not a shared medium until it gets to the ISP and the ISP should be able to handle full rate circuits internally. He should be able to get max bandwidth from his home system to his ISP's system. All our customers can. Beyond that, from his ISP to the rest of the world that is a different story. But he needs to get the bandwidth correcte dbetween himself and his ISP first. Ted ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: ADSL Bandwidth Monitoring
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Tim Daneliuk Sent: Saturday, September 08, 2007 2:01 PM To: RW Cc: freebsd-questions@freebsd.org Subject: Re: ADSL Bandwidth Monitoring RW wrote: On Sat, 08 Sep 2007 15:27:38 -0500 Tim Daneliuk [EMAIL PROTECTED] wrote: Amitabh Kant wrote: On 9/8/07, Bahman M. [EMAIL PROTECTED] wrote: I tested the connection by downloading 2~3 files simultaneously and used 'bmon' as Mel suggested in another reply (thanks to him). As I'd already guessed the RX don't get bigger than 30~40% of the expected bandwidth. I performed the test with some other files and there was no difference. Thanks, Bahman The bandwidth being advertised by your ISP would be the maximum thoughput allowed on your DSL lines with multiple DSL users sharing the same bandwidth, something that is generally known as contention ratio. See this link: http://en.wikipedia.org/wiki/Contention_ratio Amitabh But you should be able to hit the advertised bandwidth. To the best of my knowledge, DSL itself is NOT a shared medium. It is a point-to- point technology from your premise to the Central Office. The bandwidth *behind* the CO may be shared, but should be so large as to not be a bottleneck. It depends on your circumstances. Some people are constrained by contention ratio some aren't. Some ISPs offer a better ratio for a more expensive accounts. I don't understand this. If the actual DSL circuit is point-to-point - i.e., not shared between the premise and the DSLAM in the CO, just exactly *where* is the contention occuring? Inside the ISP's router. However even cheap ISP routers you can buy off Ebay for a couple grand have enough bandwidth to route between multiple 100BaseT connections. For example the 7206 has 2 800Mbt backplanes. That would mean you could run 500 1.5Mbt DSL customers at full bore to a server on your local network before contention would set in. And an ISP with that many customers can afford a more powerful router than a couple K used 7206. The upshot is his ISP doesen't know how to troubleshoot DSL. Ted ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ADSL Bandwidth Monitoring
Ted Mittelstaedt wrote: Tim Daneliuk [EMAIL PROTECTED] wrote: I don't understand this. If the actual DSL circuit is point-to-point - i.e., not shared between the premise and the DSLAM in the CO, just exactly *where* is the contention occuring? Inside the ISP's router. However even cheap ISP routers you can buy off Ebay for a couple grand have enough bandwidth to route between multiple 100BaseT connections. For example the 7206 has 2 800Mbt backplanes. That would mean you could run 500 1.5Mbt DSL customers at full bore to a server on your local network before contention would set in. And an ISP with that many customers can afford a more powerful router than a couple K used 7206. The upshot is his ISP doesen't know how to troubleshoot DSL. Ted That's more-or-less what I figured. When I switched from XO to Speakeasy, I got nearly twice the speed - i.e., What the circuit was actually supposed to do in the first place - and both use the same CO and ISP (Covad). The only other difference was that XO had me using a Speedstream and Speakeasy a Brightport bridge. No matter what XO did, they could never hold up the circuit at full speed, but Speakeasy has no problem doing this. In exchanging bridges, there is some difference, but there's no question that the provider (and their relationship with the DISP in the CO) does make a difference. -- Tim Daneliuk [EMAIL PROTECTED] PGP Key: http://www.tundraware.com/PGP/ ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ADSL Bandwidth Monitoring
On Sat, 8 Sep 2007 15:30:57 -0700 Ted Mittelstaedt [EMAIL PROTECTED] wrote: -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Amitabh Kant Sent: Saturday, September 08, 2007 12:25 PM To: Bahman M. Cc: freebsd-questions@freebsd.org Subject: Re: ADSL Bandwidth Monitoring On 9/8/07, Bahman M. [EMAIL PROTECTED] wrote: I tested the connection by downloading 2~3 files simultaneously and used 'bmon' as Mel suggested in another reply (thanks to him). As I'd already guessed the RX don't get bigger than 30~40% of the expected bandwidth. I performed the test with some other files and there was no difference. Thanks, Bahman The bandwidth being advertised by your ISP would be the maximum thoughput allowed on your DSL lines with multiple DSL users sharing the same bandwidth, something that is generally known as contention ratio. Rubbish. I work for an ISP and this is nonsense. DSL is not a shared medium until it gets to the ISP and the ISP should be able to handle full rate circuits internally. DSL is organized in different ways in different parts of the world, and contention ratio is certainly an issue in some places. The OPs email address domain is registered from addresses in Malaysia. Unless you've worked for ISPs in the country where his DSL is located, your experience isn't very relevant. I'm not saying that his problem is due to contention ratio, just that there is as yet no grounds to dismiss the suggestion as rubbish. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ADSL Bandwidth Monitoring
On 9/8/07, Ted Mittelstaedt [EMAIL PROTECTED] wrote: -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Amitabh Kant Sent: Saturday, September 08, 2007 12:25 PM To: Bahman M. Cc: freebsd-questions@freebsd.org Subject: Re: ADSL Bandwidth Monitoring On 9/8/07, Bahman M. [EMAIL PROTECTED] wrote: I tested the connection by downloading 2~3 files simultaneously and used 'bmon' as Mel suggested in another reply (thanks to him). As I'd already guessed the RX don't get bigger than 30~40% of the expected bandwidth. I performed the test with some other files and there was no difference. Thanks, Bahman The bandwidth being advertised by your ISP would be the maximum thoughput allowed on your DSL lines with multiple DSL users sharing the same bandwidth, something that is generally known as contention ratio. Rubbish. I work for an ISP and this is nonsense. DSL is not a shared medium until it gets to the ISP and the ISP should be able to handle full rate circuits internally. From the customer to the DSLAM it's a copper pair. If the DSLAM is far from the ISP backbone you have a shared connection. That's where contention is applied. If for example he has 10mbits downstream contracted and there are several power users hitting the same DSLAM and the link to the ISP isn't big enough... He should be able to get max bandwidth from his home system to his ISP's system. All our customers can. Beyond that, from his ISP to the rest of the world that is a different story. But he needs to get the bandwidth correcte dbetween himself and his ISP first. He should be able to get max bandwidth but not every ISP in the world has link bandwidth allocated for all their customers. Example: you have 100 customers with 10mbits contracted downstream. Think every ISP out there will have a 1Gbps link from the DSLAM to the backbone? Most definitely not. The same happens for mail servers. Do you believe every ISP has enough storage space to hold the advertised email storage space to their total number of customers? Most definitely not. -- Joao Barros ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
