Sipgate und File Sharing

[flitze101]

Hallo VOIP Freunde,
würde gerne mal Eure Erfahrungen hören bezüglich VOIP Calls z.B via SIPAGTE (oder auch andere) wenn parallel ein File Sharing Programm (Kaaza, edonkey etc.) läuft.
Ich selbst hab bei einer TDSL 2000/192 Flat massive Sprach Qualitätsprobleme (abgehackte Gespräche etc.), obwohl die Bandbreite theoretisch reichen sollte. D.h. die Filesharing sind so konfiguriert, dass Sie im upload max. 64 kbit/sec bandbreite ziehen).
Die Sache ändert sich auch nicht wesentlich, wenn ILBC als codec einstelle, der ja eigentlich rel. wenig Bandbreite braucht und rel. unempfindlich gegen Packetverlust ist.
Ich denke mal, dass es ein grundsätzliches QOS Problem ist, auch wenn die Bandbreite reicht.

 

[Morgi]

stimmt, wenn dein Router das nicht kann , hilft nur ein ATA486 als Router, das hat bei mir aber 100%ig auch nicht funktioniert, ging aber einigermaßen.
Meine Hoffnung liegt momentan auf einem bestellten Linksys Router......

 

[ganjamen]

lösungsvorschläge:

mehr upload bestellen.

Von adsl auf sdsl umsatteln. Adsl ist asyncroner datentransfer, wenn du 100% downstream belastest geht im upload fast nichts mehr und umgekehrt.

router mit bandbreitenmanagment, z.b. linksys, ovislink (siehe meine signatur)

oder d-link router mit 2 voip ports mit integriertem bandbreitenmanagment ( http://www.ip-phone-forum.de/forum/viewtopic.php?t=2726 )

oder draytek router mit voip features und qos (leider nur in usa ab 250$ erhältlich)


filesharing beenden.

 

[haeberlein]

Hallo!

Ich habe mit T-DSL 3000 keine Probleme ,auch wenn mein Rechner nebenbei 300kb/s saugt kann ich trotzdem problemlos telefonieren.

 

[flitze101]

Meine Hoffnung liegt momentan auf einem bestellten Linksys Router......

Hallo Morgi,
Welches Linksys Modell hast Du Dir den bestellt.
Grüsse
flitze101

 

[Morgi]

den da:
http://www.linksys.com/products/product.asp?grid=34&scid=29&prid=604

musste aber schon die Horrormeldung hier lesen , dass das teil kein echtes QOS macht sondern nur die Bevorzugung eines Ports / bzw.IP Adresse .
Da der ATA 486 aber das TOS Feld markiert ist das egal.
Filesharing mach ich nicht und WLAN brauch ich net.

 

[flitze101]

lösungsvorschläge:

"mehr upload bestellen."

Glaub daran liegts nicht unbedingt. WIe gesagt bei 192 kb/s sollte es reichen, wenn ich der filesharing nur max. 64kb zuweise


router mit bandbreitenmanagment, z.b. linksys, ovislink (siehe meine signatur)

"der ovislink scheint ja ne menge zu können. Aber ich denke mit bandbreitenmgt. alleine ist es nicht getan. Das hab ich letztlich schon manuell selbst gemacht, indem ich definiert habe das z.B edonkey nur eine bestimmte max. upload rate hat.
Ich denke man braucht einen router mit qos ist "echten" sinne, d.h. voice priosisierung bei ein/ausgehenden calls. das können auch diese modelle nicht.
Kannst Du mit Deinem ovislink "störungsfrei" telefonieren, wenn filesharing oder ander applicationen laufen?[/quote]

 

[flitze101]

Hallo!

Ich habe mit T-DSL 3000 keine Probleme ,auch wenn mein Rechner nebenbei 300kb/s saugt kann ich trotzdem problemlos telefonieren.

Wieviel upload erzeugt du denn dabei?

 

[alfa-mike]

Ich kann den Linksys WRT54G zusammen mit der HyperWRT v1.2 Firmware nur wärmstens empfehlen !

Siehe auch folgenden Thread:
http://www.ip-phone-forum.de/forum/viewtopic.php?t=2807

Den ATA486 selber als Router zu nutzen ist schon deshalb problematisch, da die Filesharing-Programme eine große Anzahl von Verbindungen aufbauen, für die der ATA486 nicht so gut ausgelegt ist wie der WRT54G.

-----
Nachtrag: Die W-Lan Funktionen des WRT54G kann man übrigens abschalten und die Antennen abschrauben. Kaufen kann man den WRT54G auch hier übers Forum.

 

[Gerd]

Hallo zusammen!

ich arbeite auch mit dem Router Linksys wrt54g und habe seit 3 Tagen die FW HyperWRT v1.1 drauf.
Kann allerdings nur bestätigen das QOS funktioniert, Achtung ohne filesharing!!!
Sobald mein eMule-Rechner in Betrieb ist mit einem max Upload von 40 kbit/s bricht QOS zusammen, habe einen Upload von 128 kbit/s zur verfügung.
Bestätige hiermit das QOS mit der FW HyperWRT, org. Linksys, sveasoft usw nicht so prickelnd ist, was ich sehr schade finde.

Gruß Gerd

 

[Christoph]

@ Robinson:

Seien wir mal ehrlich, was läuft über E-Mule ist erster Linie? Ich denke nicht, dass man hierbei eine vermeintliche "Inkompabilität" als Produktmangel ansehen kann...

 

[alfa-mike]

Wie gesagt, bei mir lief das heute wirklich problemlos. Mit Bittorrent in 5 Stunden 1,6 GB gesaugt und dabei sowohl Sipgate intern als auch ins Festnetz ohne merkliche Qualitätsunterschiede telefoniert.

Bin mal gespannt, ob das Andere bestätigen können. Also Christoph, trau dich ! hone:

 

[ganjamen]

das problem bei emule und vielen anderen filesharing programmen ist, das die router meistens keine rechenpower haben um mehrere tausend verbindungen zu verwalten.
bei vielen fabrikaten ist ab 256 verbindungen schluss, einige geräte stürzen einfach ab.

Neuer geräte mit QOS sind auch oft sehr anfällig für störungen , weil die entwickler oft nur ein QOS management hingerotzt haben das leider bei filesharing einfach überfordert ist. weil ja jedes datenpaket erst von router geprüft werden muss. das kostet rechenzeit und bringt oft grosse perfomance einbußen.

QOS funktioniert bei den meisten system spitzenmässig , wenn man einen httpdownload laufen lasst , aber nicht bei 1000 oder mehr gleichzeitigen verbindungen da ist ruckzuck feierabend.

übrigens bittorrent macht nicht sehr viele verbindungen gleichzeitig auf und ist damit relativ pflegeleicht für die meisten router mit qos.


zum ovislink router kann ich nur anmerken das er sehr stabil läuft, null probleme hat mit vielen gleichzeitgen verbindungen , da er über genug rechenpower verfügt.
übrigens hat der ovislink router diverse filesharing program ports von z.b. bittorent oder emule hardgecodet im qos integriert...

siehe auch webinterface.
http://www.ovislink.com.tw/WMU9000UI/index.files/up_qos.htm

leider kann man bis jetzt noch keine ports selber frei definieren (nur lanports) , ich hoffe das kommt in zukünfitgen firmware updates.

 

[escbln]

Ich hatte mit Emule (selbst bei ganz geringen Datenraten, 10kb Up, 20kb Down) immer Probleme, dass das Gespräch von Sip->Festnetz immer eine Zeitverzögerung von bis zu 5 Sekunden hatten, während Festnetz->Sip ganz normal war. Sobald Emule ausgeschaltet war, lief das normal. QoS hat auch nichts gebracht, weil zwar die Datenübertragungsraten in Emule runter gingen, aber das Gespräch verzögert blieb.

Dann habe ich hier gelesen, dass es mit Mldonkey besser gehen soll. Also Emule rausgeworfen und Mldonkey installiert. Tatsächlich laufen nicht nur Downloads viel besser, auch die Zeitverzögerung ist weg. Nun muss ich nur noch die Codecs ordentlich einstellen, damit die Qualität stimmt. Naja, aus einer Standard-T-Dsl-Anbindung kann man auch nicht so viel rausquetschen. Aber demnächst gönne ich mir QSC.

Der ATA 486 funktioniert mit Mldonkey bequem als Router. Ich brauchte ihn bisher noch nicht neu starten.

Esc

 

[ganjamen]

Es geht beim funktionierenden bzw. nicht funktionierenden QOS nicht um die datenraten , sonder um die anzahl der gleichzeitig offenen verbindungen.

wenn du emule laufen lässt, kannst du das gut sehen unter windows, wenn du auf START-->Ausführen gehst.. dann CMD eintippen und Enter.

dann öffnet sich das kommandozeilenfenster.

da tippst du "netstat" ein. dann werden alle verbindungen aufgelistet die euer rechner gerade in arbeit hat.

bei emule sind das sehr sehr viele

falls du andere ergebniss mit emule erziehlen willst, muss du die gleichzeitigen möglichen verbindungen verringern , das kann man direkt in emule einstellen.

 

[Blackvel]

Das Probleme bei VOIP + eMule ist, dass alle P2P Clients sehr viele Pakete erzeugen.
QOS ist eben nicht QOS.

Wenn die VOIP + eMule Pakete gemeinsam verschickt werden, klappt es nicht.

Standard QOS Implementierungen sind leider nicht so eingestellt, daß NUR VOIP mit Priorität verschickt werden.

Ich selbst habe Linksys WRT54G + eigene Firmware + eigene QOS Modifikationen, und hier klappt es selbst mit iLBC/G729A + eMule auf 64k ISDN Leitung

Das also mal grundsätzlich.

Schade dass es mit neuester Sveasoft Firmware anscheinend immer noch nicht geht, ich hatte denen eigentlich Step-by-Step Anleitung geschickt, auf was es bei VOIP + QOS ankommt.
Abwarten, es kommt bestimmt der Tag, dann tut's

@flitze01: Ich glaube nicht, dass mehr Bandbreite im Upstream 196 auf 256 oder 384 das Problem löst. Es ist ein grundsätzliches Problem der Pakete, die im DSL-Modem auflaufen und deshalb nicht rechtzeitig die VOIP-Pakete rausgeschickt werden.

 

[bjunix]

ich kann nur soviel sagen das ich mit qsc und 512 kbit upload null probleme habe. allerdings sind auch die filesahring connections auf max 75 eingestellt. reicht aber vollkommen aus.

 

[RyoBerlin]

Ja das ist wohl das beste!

Max. Connectens auf unter 100 (oder 50) setzen des weiteren max. Quellen je Datei auch auf dieselbe Zahl!
Dann darauf achten das auch WIRKLICH noch ca. 90-100Kbit/s Uploadbandbreite übrig sind! Und zwar im gesamten Netzwerk *grinz*

Bei mir läuft der Linksys Router bei 4 PCs im Netzwerk + eMule +QoS seit Alchemy 5.1 im Netzwerk ohne Probleme!

TIPP: Besorg dir mal die 30 Tage testversion des Programmes NetLimiter! damit kannst Du die Bandbreite limitieren auf dem PC stell dein emule mal upload 1Kbyte/s und probier dann telefonieren... dann berichte ma!

 

[tfi]

Habe auch schon reichlich Tests hierzu gemacht. Insgesamt denke ich, daß QoS hier keine Lösung bringen kann, denn bei A-DSL-Verbindungen werden ja auch die Pings rapide schlechter bei steigender Anzahl offener Verbindungen. Hinzu kommt die Unfähigkeit der meisten Hardware-Router, mit mehr als 300/400 Verbindungen umzugehen.

Als ich früher noch A-DSL von der Telekom und Flatrates unterschiedlicher Provider hatte, sind mir die schlechten Pings aufgefallen, die nur noch möglich waren, sobald eMule oder ein Bittorrent-Programm liefen. Es geht also nicht nur um die Bandbreite.

Seit ich auf S-DSL umgestiegen bin, treten schlechte Pings auch beim Filesharing nicht mehr auf. Bei QSC ist es tatsächlich so, daß 20er Pings auch noch möglich sind, während der Esel läuft. Da muß dann tatsächlich nur noch auf die für VoIP freie Bandbreite geachtet werden und davon hat QSC ja auch reichlich zu bieten.

 

[otaku42]

QoS bringt durchaus eine Loesung.

Das Problem bei der Sache ist, dass sich die Pakete beim DSL-Modem stauen - es transportiert die Daten nunmal deutlich langsamer in Richtung Internet, als sie aus dem lokalen Netz wieder nachgeschoben werden. Das DSL-Modem arbeitet in der Regel nach dem "First Come - First Serve"-Prinzip: was zuerst reinkommt, wird auch zuerst rausgeschickt. Die VoIP-Pakete liegen also "relativ lange" in irgendwelchen Queues rum, oder werden teilweise auch verworfen (weil die Queues ueberlaufen).

QoS kann hier gleich an zwei Stellen greifen:

1. Am Router:
Wenn der lokale Router in der Lage ist, die ausgehenden Pakete bestimmten Diensten und diesen dann unterschiedliche Prioritaeten zuzuordnen, dann kann er alle zu einer VoIP-Verbindung gehoerenden Pakete mit hoeherer Prioritaet behandeln. Sprich: die Pakete warten weniger lange darauf, auf ihren Weg in Richtung Internet geschickt zu werden. Wenn der Router dann auch noch weiss, welche Bandbreite ausgehend zur Verfuegung steht, kann er dafuer sorgen, dass die Queues im DSL-Modem nicht bis zum Anschlag gefuellt werden.

2. Im Internet:
Jedes IP-Paket kann einen Wert zugewiesen bekommen, der eine grundlegende "Behandlungsweise" fuer dieses Paket festlegt. Das kann beispielsweise "low latency" sein, oder "maximum reliability". Sofern die Router im Internet, die diese Pakete passieren muessen, diese QoS-Parameter auswerten und entsprechend beachten, kann sich die Qualitaet einer VoIP-Verbindung zusaetzlich verbessern. Das ist bisher aber leider nur selten der Fall.