---

Hej.

Jeg har nu fået mig en fin lille fiber på 10/10mbit.(50/50mbit kommer om
1md).

Jeg har langt mærke til, at hvis jeg før på min alm. ADSL forbindelse
hentede med bar 4.5mbit ud af de 8mbit total download jeg havde, så ville
pingtiderne i spil stige til 150+, mod ~25 normalt.

På mit fiber, henter jeg der med 9.5mbit ud af de mulige 10mbit, så har jeg
stadig en ping som om jeg ikke downloade noget som helst.

Hvad er grunden til den store forskel? Det er uanset om det er torents,
eller bare alm. ftp/http downloads.


--
Klaus G. // Seth-Enoch
www.seth-enoch.dk/gallery

---

On Wed, 1 Oct 2008 16:54:51 +0200, "Klaus G." <klaus_godt@hotmail.com>
wrote:

> Hvad er grunden til den store forskel? Det er uanset om det er torents,
> eller bare alm. ftp/http downloads.

Der er temmelig stor forskel på, hvordan pakker og bit bliver sendt på
de to typer linier, og den interleaving man bruger på ADSL giver meget
højere latency.

Desuden er den clockede hastighed på fiber meget højere (normalt 100
Mbps) så de enkelte bit sendes på fiber simpelthen meget hurtigere.
Udbyderne begrænser så 'kunstigt' linierne til det, man har betalt
for, men det forsinker ikke *den enkelte* bit eller pakke, kun summen
af bit og pakker.

-A
--
Heroes: Vint Cerf & Bob Kahn, Leonard Kleinrock, Robert Metcalfe, Jon Postel
Links : http://www.hojmark.net/
FAQ : http://www.net-faq.dk/

---

Asbjorn Hojmark <Asbjorn@Hojmark.ORG> wrote:

>> Hvad er grunden til den store forskel? Det er uanset om det er torents,
>> eller bare alm. ftp/http downloads.
>
>Der er temmelig stor forskel på, hvordan pakker og bit bliver sendt på
>de to typer linier, og den interleaving man bruger på ADSL giver meget
>højere latency.
>
>Desuden er den clockede hastighed på fiber meget højere (normalt 100
>Mbps) så de enkelte bit sendes på fiber simpelthen meget hurtigere.
>Udbyderne begrænser så 'kunstigt' linierne til det, man har betalt
>for, men det forsinker ikke *den enkelte* bit eller pakke, kun summen
>af bit og pakker.

... og så er forbindelsen symmetrisk i modsætning til de fleste
ADSL'er.

--
Lars Kim Lund
http://www.net-faq.dk/

---

On Wed, 01 Oct 2008 18:35:37 +0200, Lars wrote:
> Asbjorn Hojmark <Asbjorn@Hojmark.ORG> wrote:

[snip diff af dsl og fiber]

> .. og så er forbindelsen symmetrisk i modsætning til de fleste
> ADSL'er.

Det har vel principielt ingen indflydelse så længe ens upstream
aktivitet ikke kvæler upstream ACK?

--
Venlig hilsen
Michal

---

Asbjorn Hojmark <Asbjorn@Hojmark.ORG> writes:

> On Wed, 1 Oct 2008 16:54:51 +0200, "Klaus G." <klaus_godt@hotmail.com>
> wrote:
>
>> Hvad er grunden til den store forskel? Det er uanset om det er torents,
>> eller bare alm. ftp/http downloads.
>
> Der er temmelig stor forskel på, hvordan pakker og bit bliver sendt på
> de to typer linier, og den interleaving man bruger på ADSL giver meget
> højere latency.
>
> Desuden er den clockede hastighed på fiber meget højere (normalt 100
> Mbps) så de enkelte bit sendes på fiber simpelthen meget hurtigere.
> Udbyderne begrænser så 'kunstigt' linierne til det, man har betalt
> for, men det forsinker ikke *den enkelte* bit eller pakke, kun summen
> af bit og pakker.

Ja og nej. Den højere klokkede hastighed hjælper kun på at få pakkerne
sendt/modtaget på fiber linken (time-of-flight på fiberen er den
samme), og dét har jeg svært ved at se som den begrænsende faktor.

Uden at kende hvilke routere/netværk som ADSL hhv fiber er koblet op
på, vil jeg pege på at fiber-routeren sandsynlgivis implementerer en
bedre QoS som giver en fordel til ICMP og network management traffik.


Kai
--
Kai Harrekilde-Petersen <khp(at)harrekilde(dot)dk>

---

On Thu, 02 Oct 2008 15:35:14 +0200, Kai Harrekilde-Petersen
<khp@harrekilde.dk> wrote:

> Ja og nej. Den højere klokkede hastighed hjælper kun på at få pakkerne
> sendt/modtaget på fiber linken (time-of-flight på fiberen er den
> samme), og dét har jeg svært ved at se som den begrænsende faktor.

Der er meget stor forskel på, om pakkerne faktisk sendes som 100 Mbps
(og man så dropper 'overskydende' trafik over hvad kunder betaler for)
eller om de sendes med 20 Mbps.

På en 20 Mbps fibernet-forbindelse, sendes pakkerne faktisk med 100
Mbps (med mindre det er en gigabit-forbindelse, men dem er der ikke
mange af endnu), mens de på en ADSL-forbindelse sendes med whatever
linien kører (fx. 20 Mbps, dog med hensyntagen til interleaving).

> Uden at kende hvilke routere/netværk som ADSL hhv fiber er koblet op
> på, vil jeg pege på at fiber-routeren sandsynlgivis implementerer en
> bedre QoS som giver en fordel til ICMP og network management traffik.

Jeg kender en hel del af fibernet-implementationer herhjemme, og der
er *ingen* af dem, der opprioriterer ICMP.

-A
--
Heroes: Vint Cerf & Bob Kahn, Leonard Kleinrock, Robert Metcalfe, Jon Postel
Links : http://www.hojmark.net/
FAQ : http://www.net-faq.dk/

---

Asbjorn Hojmark <Asbjorn@Hojmark.ORG> writes:

> On Thu, 02 Oct 2008 15:35:14 +0200, Kai Harrekilde-Petersen
> <khp@harrekilde.dk> wrote:
>
> Der er meget stor forskel på, om pakkerne faktisk sendes som 100 Mbps
> (og man så dropper 'overskydende' trafik over hvad kunder betaler for)
> eller om de sendes med 20 Mbps.
>
> På en 20 Mbps fibernet-forbindelse, sendes pakkerne faktisk med 100
> Mbps (med mindre det er en gigabit-forbindelse, men dem er der ikke
> mange af endnu), mens de på en ADSL-forbindelse sendes med whatever
> linien kører (fx. 20 Mbps, dog med hensyntagen til interleaving).

Jeg er enig i dit argument, men jeg kan ikke få tallene til at stemme.

På en 100Mbit Ethernet fiber vil en 64 byte ICMP pakke tage 512 * 10
ns = 5.12 us at sende/modtage.

Ved 20Mbit vil dette blive 5x langsommere, dvs 25.6us, hvis man kan se
bort fra interleaving.

Selv på mit Gigabit LAN måler jeg over 100us, så det er usandsynligt
at liniehastigheden i sig selv (som giver godt 20 us) giver en målbar
forskel i ping tider.

Så det det må være en ret heftig interleaving på ADSL, som giver det
stort bidrag til latency.


Kai
--
Kai Harrekilde-Petersen <khp(at)harrekilde(dot)dk>

---

On Thu, 02 Oct 2008 16:08:06 +0200, Kai Harrekilde-Petersen
<khp@harrekilde.dk> wrote:

> Jeg er enig i dit argument, men jeg kan ikke få tallene til at stemme.

Det er ikke så interessant, hvor lang tid det tager at sende pakken
selv (som du regnede på). OP spurgte til, hvorfor en download ikke i
nævneværdig grad gav dårlige pingtid på fiberforbindelsen, og en af
faktorerne er som sagt, at man kan komme til at vente på, noget andet
bliver sendt først.

Det 'noget andet', ICMP-pakken kommer til at vente på ved en samtidig
down- eller upload, er pakker i max-størrelse (1500B), og det kan godt
være mere end en enkelt (hvilket naturligvis giver jitter).

Der er 'nogen forskel' på, om man (ICMP-pakken) skal vente på, at der
bliver sendt fx tre 1500 B pakker ved 100 Mbps eller tre 1500 B pakker
ved 8 Mbps, eller for den sags skyld (i den modsatte retning) tre 1500
B pakker ved 512 Kbps.

Og så er det som sagt ikke den eneste forskel.

-A
--
Heroes: Vint Cerf & Bob Kahn, Leonard Kleinrock, Robert Metcalfe, Jon Postel
Links : http://www.hojmark.net/
FAQ : http://www.net-faq.dk/

---

Asbjorn Hojmark <Asbjorn@Hojmark.ORG> writes:

> On Thu, 02 Oct 2008 16:08:06 +0200, Kai Harrekilde-Petersen
> <khp@harrekilde.dk> wrote:
>
>> Jeg er enig i dit argument, men jeg kan ikke få tallene til at stemme.
>
> Det er ikke så interessant, hvor lang tid det tager at sende pakken
> selv (som du regnede på). OP spurgte til, hvorfor en download ikke i
> nævneværdig grad gav dårlige pingtid på fiberforbindelsen, og en af
> faktorerne er som sagt, at man kan komme til at vente på, noget andet
> bliver sendt først.

Den køber jeg ikke.

> Det 'noget andet', ICMP-pakken kommer til at vente på ved en samtidig
> down- eller upload, er pakker i max-størrelse (1500B), og det kan godt
> være mere end en enkelt (hvilket naturligvis giver jitter).
>
> Der er 'nogen forskel' på, om man (ICMP-pakken) skal vente på, at der
> bliver sendt fx tre 1500 B pakker ved 100 Mbps eller tre 1500 B pakker
> ved 8 Mbps, eller for den sags skyld (i den modsatte retning) tre 1500
> B pakker ved 512 Kbps.

Det er ikke så interessant hvor lang tid det tager at sende 3 1500B
pakker ved 100Mbps, når linien er shapet til 20Mbps - så er det
interessant hvor lang tid det tager ved 20Mbps. Ja, den enkelte
pakker bliver sendt med 100Mbps, men for at simulere en 20Mbps linie,
indsættes en forsinkelse før den næste pakke sendes*. Ellers vil
linien jo se ud som en 100Mbps linie

*) Typisk har man også en 'burst size' som fortæller hvor mange bytes
du har lov til at sende i rap, hvis linien har været tom i et stykke
tid. Men dette er ikke tilfældet for OP, idet OP måler ping tiderne
under en større download.

Så du har stadigvæk ikke kommet med en rimelig forklaring på hvorfor
ping tiderne ikke ændrer sig. En mulig forklaring er QoS, men det har
du afvist udfra din praktiske erfaring med fiber routere.


Kai
--
Kai Harrekilde-Petersen <khp(at)harrekilde(dot)dk>

---

On Thu, 02 Oct 2008 20:46:48 +0200, Kai Harrekilde-Petersen
<khp@harrekilde.dk> wrote:

> Det er ikke så interessant hvor lang tid det tager at sende 3 1500B
> pakker ved 100Mbps, når linien er shapet til 20Mbps - så er det
> interessant hvor lang tid det tager ved 20Mbps. Ja, den enkelte
> pakker bliver sendt med 100Mbps, men for at simulere en 20Mbps linie,
> indsættes en forsinkelse før den næste pakke sendes*.

Typisk[1] policer man på ingress, og det gør man *altid* med et burst
vindue og *aldrig* med et burst vindue på enkelte pakker. Jeg bruger
som tommelfingerregel (rate/8)*1,5 til policing, hvilket ved 25 Mbps
giver et burst-vindue på næsten 5 MB.

> Så du har stadigvæk ikke kommet med en rimelig forklaring [...]

Nu skylder jeg jo sådan set heller ikke dig sådan en...

-A
[1] Jeg kender ingen, der shape'er på ingress.
--
Heroes: Vint Cerf & Bob Kahn, Leonard Kleinrock, Robert Metcalfe, Jon Postel
Links : http://www.hojmark.net/
FAQ : http://www.net-faq.dk/

---

Asbjorn Hojmark <Asbjorn@Hojmark.ORG> writes:

> On Thu, 02 Oct 2008 20:46:48 +0200, Kai Harrekilde-Petersen
> <khp@harrekilde.dk> wrote:
>
>> Det er ikke så interessant hvor lang tid det tager at sende 3 1500B
>> pakker ved 100Mbps, når linien er shapet til 20Mbps - så er det
>> interessant hvor lang tid det tager ved 20Mbps. Ja, den enkelte
>> pakker bliver sendt med 100Mbps, men for at simulere en 20Mbps linie,
>> indsættes en forsinkelse før den næste pakke sendes*.
>
> Typisk[1] policer man på ingress, og det gør man *altid* med et burst
> vindue og *aldrig* med et burst vindue på enkelte pakker. Jeg bruger
> som tommelfingerregel (rate/8)*1,5 til policing, hvilket ved 25 Mbps
> giver et burst-vindue på næsten 5 MB.

Policing på ingress, shaping på egress er normalen, ja. Siger du
dermed at en router benytter policing fremfor shaping for at ramme den
aftalte båndbredde? Hvad er det lige fordelen ved dette skulle være?

>> Så du har stadigvæk ikke kommet med en rimelig forklaring [...]
>
> Nu skylder jeg jo sådan set heller ikke dig sådan en...

Jeg savner bare at du kommer lidt mere aktivt frem på banen med din
erfaring, istedet for at pege på hvorfor det jeg foreslår ikke er
korrekt. Men det er nok bare mig.


Kai
--
Kai Harrekilde-Petersen <khp(at)harrekilde(dot)dk>

---

Kai Harrekilde-Petersen wrote:

> Policing på ingress, shaping på egress er normalen, ja.

Det kommer an på. Det er absolut ikke unormalt også at lave egress policing.

> Siger du dermed at en router benytter policing fremfor shaping for at
> ramme den aftalte båndbredde? Hvad er det lige fordelen ved dette
> skulle være?

Det er meget udbredt kun at bruge policing i mange net. En årsag til
dette er ofte, at shaping ikke er understøttet på det anvendte udstyr.


--
Jens

---

Jens Fallesen <jf@avicnet.co.uk> writes:

> Kai Harrekilde-Petersen wrote:
>
>> Policing på ingress, shaping på egress er normalen, ja.
>
> Det kommer an på. Det er absolut ikke unormalt også at lave egress policing.

Eh? - så hvis man overstiger policing regler, bliver pakkerne blot
smidt væk. Ouch. Men er selvfølgelig nemt og koster ikke memory

>> Siger du dermed at en router benytter policing fremfor shaping for at
>> ramme den aftalte båndbredde? Hvad er det lige fordelen ved dette
>> skulle være?
>
> Det er meget udbredt kun at bruge policing i mange net. En årsag til
> dette er ofte, at shaping ikke er understøttet på det anvendte udstyr.

OK.

Kai
--
Kai Harrekilde-Petersen <khp(at)harrekilde(dot)dk>

---

On Sat, 18 Oct 2008 17:14:09 +0200, Kai Harrekilde-Petersen
<khp@harrekilde.dk> wrote:

> Eh? - så hvis man overstiger policing regler, bliver pakkerne blot
> smidt væk.

Ja, sådan laver man policing.

> Ouch.

Hvis kunden har en 20 Mbps DSL-forbindelse, og der kommer mere end 20
Mbps, bliver pakkerne jo også 'blot smidt væk'.

-A
--
Heroes: Vint Cerf & Bob Kahn, Leonard Kleinrock, Robert Metcalfe, Jon Postel
Links : http://www.hojmark.net/
FAQ : http://www.net-faq.dk/

---

Asbjorn Hojmark wrote:
> On Sat, 18 Oct 2008 17:14:09 +0200, Kai Harrekilde-Petersen
> <khp@harrekilde.dk> wrote:
>
>> Eh? - så hvis man overstiger policing regler, bliver pakkerne blot
>> smidt væk.
>
> Ja, sådan laver man policing.


Ikke altid - en mere intelligent måde er her:


Følgende gælder for visse supervisor engines i Catalyst 4500 og 4900:
http://www.cisco.com/en/US/docs/switches/lan/catalyst4500/12.1/19ew/configuration/guide/qos.html#wp1271743
http://www.cisco.com/en/US/docs/switches/lan/catalyst4500/12.2/46sg/configuration/guide/qos.html#wp1463285
Citat: "...When the queue length of a flow exceeds its limit, DBL will
drop packets or set the Explicit Congestion Notification (ECN) bits in
the packet headers..."


http://en.wikipedia.org/wiki/Explicit_Congestion_Notification
Citat: "...
A router that detects impending congestion may choose to mark an
ECN-capable packet with the congestion experienced codepoint rather than
dropping it outright.
....
A recent proposal[2] suggests marking SYN-ACK packets as ECN-capable.
This improvement, known as ECN+, has been shown to provide dramatic
improvements to performance of short-lived TCP connections.
....
Effects on performance

Since ECN is only effective in combination with an Active Queue
Management (AQM) policy, the benefits of ECN depend on the precise AQM
being used. A few observations, however, appear to hold across different
AQMs.

As expected, ECN reduces the number of packets dropped by a TCP
connection, which, by avoiding a retransmission, reduces latency and
especially jitter. This effect is most drastic when the TCP connection
has a single outstanding segment[4], when it is able to avoid an RTO
timeout; this is often the case for interactive connections (such as
remote logins) and transactional protocols (such as HTTP requests, the
conversational phase of SMTP, or SQL requests).

Effects of ECN on bulk throughput are less clear[5], due to the fact
that modern TCP implementations are fairly good at resending dropped
segments in a timely manner when the sender's window is large.

Use of ECN has been found to be detrimental to performance on highly
congested networks when using AQM algorithms that never drop packets[6].
Modern AQM implementations avoid this pitfall by dropping rather than
marking packets at very high load.
...."


Visse supervisor engines i Catalyst 4500 og 4900 kan sættes op til at
gøre følgende:
http://www.cisco.com/en/US/docs/switches/lan/catalyst4500/12.2/46sg/configuration/guide/qos.html#wp1463285
Citat: "...
DBL [Dynamic buffer limiting] classifies flows in two categories,
adaptive and aggressive. Adaptive flows reduce the rate of packet
transmission once it receives congestion notification [ECN signalering].
Aggressive flows do not take any corrective action in response to
congestion notification. For every active flow the switch maintains two
parameters, "buffersUsed" and "credits". All flows start with
"max-credits", a global parameter. When a flow with credits less than
"aggressive-credits" (another global parameter) it is considered an
aggressive flow and is given a small buffer limit called
"aggressiveBufferLimit".
...."

-

Implementation and Deployment of ECN:
http://www.icir.org/floyd/ecn.html#implementations
Citat: "...
# Microsoft Vista supports ECN, but it is disabled by default.
Implementation report from March 2007.
# MAC OS X:
Leopard 10.5.0 implements ECN, controlled by the variables
"net.inet.tcp.ecn_negotiate_in" and "net.inet.tcp.ecn_initiate_out".
Reported by Rui Paulo, 2007.
# Linux:

* Linux 2.4 has full ECN support, including ECN TCP. January 2001.
* Linux 2.3: The Linux 2.3 kernel includes the router code for ECN.
May 1999.

# FreeBSD: Rui Paulo added TCP ECN end-host support to FreeBSD 8.0. July
2008.
....
Cisco:
Cisco supports ECN starting from 12.2(8)T. August 2006.
...."

hilsen

Glenn

>
>> Ouch.
>
> Hvis kunden har en 20 Mbps DSL-forbindelse, og der kommer mere end 20
> Mbps, bliver pakkerne jo også 'blot smidt væk'.
>
> -A

---

On Sun, 19 Oct 2008 14:36:47 +0200, Glenn Møller-Holst <nomail@xx.dk>
wrote:

>>> Eh? - så hvis man overstiger policing regler, bliver pakkerne blot
>>> smidt væk.

>> Ja, sådan laver man policing.

> Ikke altid - en mere intelligent måde er her:

DBL er ikke policing, men en congestion avoidance-mekanisme, og er
altså mere sammenligneligt med RED og WRED.

> Følgende gælder for visse supervisor engines i Catalyst 4500 og 4900:

Når man laver policing på 4500 foregår det også ved at smide data væk.
Som sagt er det nu engang sådan, man laver polcing.

-A
PS: Kan du ikke skære ned på citaterne fra eksterne kilder?
--
Heroes: Vint Cerf & Bob Kahn, Leonard Kleinrock, Robert Metcalfe, Jon Postel
Links : http://www.hojmark.net/
FAQ : http://www.net-faq.dk/

---

Asbjorn Hojmark wrote:
> On Sun, 19 Oct 2008 14:36:47 +0200, Glenn Møller-Holst <nomail@xx.dk>
> wrote:
>
>>>> Eh? - så hvis man overstiger policing regler, bliver pakkerne blot
>>>> smidt væk.
>
>>> Ja, sådan laver man policing.
>
>> Ikke altid - en mere intelligent måde er her:
>
> DBL er ikke policing, men en congestion avoidance-mekanisme, og er
> altså mere sammenligneligt med RED og WRED.
>
>> Følgende gælder for visse supervisor engines i Catalyst 4500 og 4900:
>
> Når man laver policing på 4500 foregår det også ved at smide data væk.
> Som sagt er det nu engang sådan, man laver polcing.
>
> -A
> PS: Kan du ikke skære ned på citaterne fra eksterne kilder?

Hej Asbjorn

Det kommer an på hvor snævert man fortolker policy og policing. Hvis
policy fortolkes som datanet politik(ker), kan undgåelse af
datanet-trafikforstoppelse (congestion avoidance) fint indgå.

Det er jo en valgt datanet politik om man ønsker at en køs middellængde
forsøges holdt under et vist niveau.

Men jeg har nu opdaget, at det var en snævere fortolkning du svarede på.

-

Herudover vises et eksempel på police exceed actions - det behøver ikke
kun at være drop, selv med den snævrere policing fortolkning:

http://www.cisco.com/en/US/products/hw/switches/ps663/products_tech_note09186a00800946e9.shtml
Citat: "...
Policing function allows either dropping out-of-profile traffic or
marking the traffic down to a different Differential Services Code Point
(DSCP) value to enforce contracted service level.
....
This document is not restricted to specific software and hardware versions.
...."

hilsen

Glenn

---

On Sun, 19 Oct 2008 18:59:26 +0200, Glenn Møller-Holst <nomail@xx.dk>
wrote:

> Men jeg har nu opdaget, at det var en snævere fortolkning du svarede på.

Ja, vi snakker jo om at begrænse brugeres praktisk tilgængelige
båndbredde.

> Herudover vises et eksempel på police exceed actions - det behøver ikke
> kun at være drop, selv med den snævrere policing fortolkning:

At mærke trafik ned giver ikke mening i forbindelse med at begrænse
praktisk tilgængelig båndbredde. Eneste praktiske anvendelige action
er derfor drop.

-A
--
Heroes: Vint Cerf & Bob Kahn, Leonard Kleinrock, Robert Metcalfe, Jon Postel
Links : http://www.hojmark.net/
FAQ : http://www.net-faq.dk/

---

On Thu, 02 Oct 2008 22:05:46 +0200, Asbjorn Hojmark
<Asbjorn@Hojmark.ORG> wrote:

> [1] Jeg kender ingen, der shape'er på ingress.

Rettelse: Jeg er kommet i tanker om et af energiselskaberne, der gør
det.

-A
--
Heroes: Vint Cerf & Bob Kahn, Leonard Kleinrock, Robert Metcalfe, Jon Postel
Links : http://www.hojmark.net/
FAQ : http://www.net-faq.dk/

---

Hej.

Jeg takker for jeres svar. Selvom jeg faldt af da i gik i gang med at
diskutere og fagudtrykkene begyndte at flyve højt! :)


--
Klaus G. // Seth-Enoch
www.seth-enoch.dk/gallery