Upc totaalpakket

[Verwijderd]

ik heb sinds vandaag upc internet 10mbps down en 1.5 mbps up en ik haal die snelheden ook gewoon alleen als ik bijv. met utorrent download haal ik maar 500kb/s max. weet iemand wat de oorzaak hiervan is en hoe ik het kan oplossen?

[Verwijderd]

Vertel eens wat meer? Met welke OS?

[Verwijderd]

windows xp en geen router ofzo gewoon met het modem dat ik heb gekregen van upc geen firewall ofzo

[job]

De download snelheid waarmee je daadwerkelijk download is natuurlijk niet alleen afhankelijk van jouw maximale download, maar ook van de upload van de partij waar je het vandaan haalt.

Als het echter altijd vrij laag is, je geen router hebt, dan zou je kunnen kijken naar je torrent software.

[Verwijderd]

dat weet ik maar bij mijn vorige internet provider haalde ik bij dezelfde site met dezelfde torrent wel hoger en bij speedtests zit ik op 1100kb/s

[job]

Ja, dat zei je er niet bij.
In elkgeval, al geprobeerd met encryptie?

[Verwijderd]

ja maar nog steeds hetzelfde probleem met Azureus en met Utorrent en ik haal trouwens ook hele lage uploadsnelheden 0.3kb/s nu maar en heeft upc dan ook een nieuwsserver kijken hoe snel ik daar vanaf download..?

[ Voor 52% gewijzigd door Verwijderd op 19-06-2008 20:06 ]

[Erwin1967]

Verwijderd schreef op donderdag 19 juni 2008 @ 20:00:
ja maar nog steeds hetzelfde probleem met Azureus en met Utorrent en ik haal trouwens ook hele lage uploadsnelheden 0.3kb/s nu maar en heeft upc dan ook een nieuwsserver kijken hoe snel ik daar vanaf download..?

UPC knijpt op bepaalde poorten tijdens de avonduren (traffic shaping). Bekende poorten zijn van news en bittorrent. Voor news gebruik ik SSL waardoor een andere poort wordt gebruikt en ervaar ik (nog) geen snelheidsverlies. Maar zodra dit door teveel mensen gedaan wordt zal het dataverkeer te groot worden waardoor UPC ook deze poorten zal 'managen'

[dion_b]

Waar komt dat poorten-verhaal nou toch vandaan

Doe even de moeite je in te lezen voordat je broodjes aap doorvertelt
Wikipedia: Traffic shaping

Poortnummer maakt geen drol uit, het gaat om de inhoud van de headers. Dat SSL werkt komt niet doordat het op een andere poort zit, maar omdat de BT/Usenet headers dan gencrypteerd meegestuurd worden in SSL-pakketten.

Geloof je me niet? Probeer het via SSL op de reguliere poorten _{wat *is* trouwens een "bekende" poort voor BT?} , en je zult zien dat het even snel gaat als met SSL op andere poorten. Probeer zonder SSL op willekeurig welke poort en het gaat even traag.

[Erwin1967]

dion_b schreef op vrijdag 20 juni 2008 @ 12:46:
Waar komt dat poorten-verhaal nou toch vandaan

Doe even de moeite je in te lezen voordat je broodjes aap doorvertelt
Wikipedia: Traffic shaping

Poortnummer maakt geen drol uit, het gaat om de inhoud van de headers. Dat SSL werkt komt niet doordat het op een andere poort zit, maar omdat de BT/Usenet headers dan gencrypteerd meegestuurd worden in SSL-pakketten.

Ik zou eerst zelf eens de wiki ff doorlezen :

Simple traffic shaping schemes shape all traffic uniformly by rate. More sophisticated shapers first classify traffic. Traffic classification categorises traffic (for example, based on port number or protocol).

De methode is relatief eenvoudig. Nieuws gaat altijd via 119. Nieuws lezen via SSL gaat via een andere poort (standaard 563). Blijkt het dataverkeer over een poort hoger dan verwacht mag worden knijp je gewoon de poort dicht (vertragen pakketjes). Ik heb op diverse forums al gelezen dat ook news via SSL geknepen wordt. Dit laatste is ook in tegenspraak met wat jij ff snel beweert. Ik denk dat je de TCP header verwart met de datainhoud (met daarin de news headers).
Het knijpen van news via SSL lijkt ook van de locatie af te hangen. Dit gebeurt minder vaak omdat weinig mensen via SSL werken.

[ Voor 3% gewijzigd door Erwin1967 op 20-06-2008 14:53 ]

[Mr. Blonde]

En toch ben ik het met dion_b eens. het werkt d.m.v. encryptie en de poorten maken eigenlijk niet uit.
Ik maak er gebruik van met het downloaden van usenet omdat UPC op werkdagen de boel knijpt zo tussen 19:00 en 22:00 uur. weet niet of het nu ook zo is omdat van SSL gebruik maak.

het werkt dus omdat UPC niet kan zien wat voor soort verkeer er gaat over het netwerk. De poort maakt niet uit. Wel is et zo dat bijv. newsleecher als je SSL gebruikt standaard poort 563 gebruikt

[KillerAce_NL]

dion_b schreef op vrijdag 20 juni 2008 @ 12:46:
Waar komt dat poorten-verhaal nou toch vandaan

Doe even de moeite je in te lezen voordat je broodjes aap doorvertelt
Wikipedia: Traffic shaping

Poortnummer maakt geen drol uit, het gaat om de inhoud van de headers. Dat SSL werkt komt niet doordat het op een andere poort zit, maar omdat de BT/Usenet headers dan gencrypteerd meegestuurd worden in SSL-pakketten.

Geloof je me niet? Probeer het via SSL op de reguliere poorten _{wat *is* trouwens een "bekende" poort voor BT?} , en je zult zien dat het even snel gaat als met SSL op andere poorten. Probeer zonder SSL op willekeurig welke poort en het gaat even traag.

Niks broodje aap, UPC knijpt gewoon poorten, dat is bekend. Ook Usenet knijpen ze.

[IEF]

Een simpele methode van Traffic Shaping zou inderdaad zijn 'bekende' poorten af te knijpen.

Omdat dit zo ontzettend simpel te omzeilen is (gebruik een andere poort), is het voor een ISP wenselijk om packet inspection te gebruiken, dat heeft niets meer met de poort te maken.

Encryptie is dan in principe de enige mogelijkheid om dat te 'omzeilen'. Geen packetinspectie -> Inhoud onbekend -> niet afknijpen.

Laten we de Trafficshaping discussie laten voor wat 'ie is.

@TS: Beschrijf je situatie eens iets uitvoeriger.
Het is onduidelijk of je een modem hebt, of dat UPC wellicht een modem/router levert standaard.
Is dat het geval (of heb je een firewall), dan dien je poorten te openen / te forwarden voor je torrent client. Vooral de door jou vermelde uploadsnelheden van "0.3 KB/s" klinken naar een poorten/configuratie-verhaal.
Deze zaken zijn uitvoerig beschreven in diverse topics hier. Anders kun je ook bijv. terecht op www.portforward.com,

[dion_b]

Erwin1967 schreef op vrijdag 20 juni 2008 @ 14:49:
[...]


Ik zou eerst zelf eens de wiki ff doorlezen :

Simple traffic shaping schemes shape all traffic uniformly by rate. More sophisticated shapers first classify traffic. Traffic classification categorises traffic (for example, based on port number or protocol).

De methode is relatief eenvoudig. Nieuws gaat altijd via 119. Nieuws lezen via SSL gaat via een andere poort (standaard 563). Blijkt het dataverkeer over een poort hoger dan verwacht mag worden knijp je gewoon de poort dicht (vertragen pakketjes). Ik heb op diverse forums al gelezen dat ook news via SSL geknepen wordt. Dit laatste is ook in tegenspraak met wat jij ff snel beweert. Ik denk dat je de TCP header verwart met de datainhoud (met daarin de news headers).
Het knijpen van news via SSL lijkt ook van de locatie af te hangen. Dit gebeurt minder vaak omdat weinig mensen via SSL werken.

Ik heb in mijn post toch duidelijk een manier gegeven waarop je voor jezelf kunt nagaan of het per poort of dmv packet inspection gaat. Wat is jouw resultaat daar dan van