This has gone to a point where it drives me completely mad.

I have a connection of 100/10 mbit and ComHem is my ISP. They're known in quake to be worthless, but it's been fine in the past (or at least somewhat fine) but the last weeks it's been completely horrible. From 12-13 CET to 05-06 CET it's near impossible to play. Anything between 4 and 60% packetloss and 20-40ms instead of 12ms. I have no idea why this is happening, so I tried a few things.

I of course did the usual with checking cables/letting the modem rest and so on before restarting it so it's nothing local.

I talked to Locust who sells connections for another company and he's got the same problem (others that have it; razor, rigormortis etc etc, so it's a kinda wide problem) and he tells me it's because of what kind of service I have. Something about the contacts in the wall (where you recieve the stream from the ISP). Note that this is a copper-net and not fibre. Locust also said that the only way to change this is to simply change ISP and service to e.g ADSL.

When calling the ISP customer support, they only ping your modem and when the result turns out fine, they say that there's something wrong with my game and not with their service. Appearently they hardly even know what packetloss is. And they won't care about it, since most that use their service use it for games like World of Warcraft/starcraft etc where the packetloss almost goes unnoticable, or surfing the web/downloading stuff. Worth mentioning might be also that TPTESTs turn out just fine with downstream/upstream, so there's nothing wrong with the speed up/down.

I have no idea what I could possibly do to make quake even playable. Especially since I get both TV and telephone through the same service, so changing ISP for my internet connection would require me to change EVERYTHING.

Does anyone with knowledge about this kind of stuff have any idea what one could do? I turn my questions here since people on this forum are more well educated in the area than the people at my ISP customer support.

Any answer is appreciated and if there's something more you need to know to come up with an idea, please ask and I'll find out.

Thanks,
andeh

[EDIT: I might add though that it's not even noticable when surfing/teamspeak/ventrilo/mumble/starcraft/WoW which makes it so weird. I'm thinkin, shouldn't teamspeak for example take real damage from packetloss? But I never had any problem there at all :X]

Seriously: ask them to exclude the internet part of that service and get something, anything, else.
I have only heard bad things about comhem since I first heard of their so called internet connections

Haven't heard anything about Comhem since back in the days when everybody was avoiding them. Amazing that they still can't provide proper internet to people. The reason why they don't understand your problem is that all the gamers have changed ISP years ago and you are probably the only one left complaining :E

The reason to this thread was actually if there's anybody out there who has any idea whatsoever of something that could be done APART from changing ISP ^.^ something I could tell them, something I could do myself, anything really. Some arguement I could use, anything of technical interest that they might understand to understand the problem, anything could help if lucky.

@Hooraytio: it's some kind of package with everything included which makes it alot harder to just exclude something now that I already have it. My dad should have thought about that before getting it - if only he was a quaker. ^.^

Sorry to hear that man but as you said, they dont understand your problem and quite frankly they dont care.

Yeah, that was the whole point of my post.

They don't care since they don't understand the problem. It works to surf on the internet, and that's all comhem is good for and always have been. Nobody uses it for playing games. As soon as everybody realized how crap it was for playing games 10 years ago everybody switched to another ISP and never went back to Comhem. You are unfortunately fighting a battle all alone :-(

Can't you use run some pings / tracert when you have packet loss make some screenshots and send it to them? Also make sure you ping/tracert some good know servers liek a big news site orsomething.

Otherwise they will blame the one running the other server.

No there is nothing to be done. If your connection with the current ISP sux, then it sux, period. Well I guess you can always tell them that no one else from around the world has the problems on the same server that you do. So it's hardly the server.

This is also my experience - if an ISP is shite, then no amount of complaining will help, and the only solution is to change.

:nws:

Hmm, the weird part I guess is that it was way better just a few weeks ago. It comes in periods, and during the night it's all fine so it seems whenever loads of people use the ISP's service they get overloaded or sumthing as nights/mornings are fine and 12ms 0pl.

But anyway, is any of these answers actually educated evaluations? Sounds more like "ISP sux, change", does anyone know even why this problem is? Any comments on the stuff Locust talked about? Someone has to know more about this.

We're dealing with the same sh*t here, ISP dropping UDP packets randomly. Note: you don't perceive the packet-loss in other SW probably because those work via TCP protocol, which ensures reliability. UDP does not ensure reliability. Quake(World) communicates via UDP and uses it's own implementation of reliable transfer only for some stuff (chat, player info, etc.), most of the stuff is delivered unreliably and that's why you can see the packet-loss.

What we did here is we got ourselves the hrping utility and we launched it with parameters so that it simulates QuakeWorld traffic:
-s 13 <- delay between QW packets is 1/77 = 12.9 ms
-l 50 <- average size of QuakeWorld packet (type /show net in ezQuake to check how large packets are being send and how it varies when you start shooting, moving, more players join, etc.)

After I launch hrping configured like this (pinging the closest QW server, which by coincidence lies within ISP's network), I get no packet-loss whatsoever. Therefore I am for example going to ask my ISP why they are dropping UDP packets while ICMP (type of packets sent by ping utilities) can make it through without problems.

What you can also do is get yourself Qizmo and use it's tcpconnect functionality (you launch your local Qizmo and connect through to some external Qizmo via TCP, that way you get 0% PL and you are outside of your shitty ISP's network, then you connect with that Qizmo wherever you want).

Also, you can get some recent-enough ezQuake and connect to public servers with /tcpconnect command, however only some servers have their ports opened for this type of connection.

They have oversold their capacity, either in your area or in the backbone. You answered to yourself already. "it seems whenever loads of people use the ISP's service they get overloaded"

I was going to suggest the same as johnny_cz, as well as setting the proper delay and size parameters in a decent ping utility, you could set it to run each hour (or more frequent) for days, to a randomised array of different hosts to prove to your ISP (they already know, but to show them that you know and are angry about it) that it is a consistent predictable problem with their network. In Australia we have whirlpool.net.au which has a forum among other things dedicated to most ISPs, where most of the ISPs are officially represented, threads and PMs to ISP reps tend to get (after you demonstrate that its a legitimate problem) problems fixed quicker, better, and more often. Is there a similar array of ISP forums near you? A place ISPs can't neglect because they are collectively shamed/lauded/compared by millions of, more or less informed users.


That might work for you johnny, because you implied your ISP are giving less priority (or something) to UDP, but that doesn't sound like Andeh's problem. I thought the whole reason we used UDP for games is because TCP, with it's sequential(?) forced reliable way of delivering packets would be too slow, or is that overcome by more bandwidth etc.? It's also definitely worth using qizmo to duplicate and compress (different forms of compression depending on how much PL) packets.

Offtopic could you use qizmo's tcp ability to disguise, to some degree, game traffic as http

cl_c2spps can fix the pl, but will give you a higher ping, and you will appear a bit laggy to other players

That's so much inferior to Qizmo's compression.

Johnny, with using TCP for QW, is it a modified version of TCP that will drop packets after they are too delayed to be good?

These were the kind of answers I was looking for awesome guys!

Since I am an idiot though, is there any chance we could meet up sometime JohnNy_cz? For a bit more "help", or rather you telling me exactly what to do and I'll simply carry your orders out In the process I might learn a thing or two as well. Would be greatly appreciated!

If possible, contact me on irc whenever you're there and got time. I'm basically available 24 hours a day.

Thanks again guys,
andeh

Have you tried Qizmos option where U can send packets twice to minimize packetloss? If you've such a bandwith sending packets twice or even 3 times shouldn't be a problem.

edit.

didn't read johnny's reply, so i suppose that's the real solution.

Hmm, tried Qizmo now and even sending 3x packets (could even try 4x though) but it didn't make much difference..

I tried that Qizmo repeating packets too, but to my surprise it did not have any effect. I remember during my modem times, it DID lower my PL, but here now it does not. Another thing I noticed is that cl_physfps 50 makes my PL go away (I don't believe in cl_c2spps, the results of that are too shitty .. OTOH cl_physfps 50 is unplayable). It's like if ISP is filtering/dropping everything that goes above 50 packets per second or smth...

So my best bet is to?

By the way, thanks for all the help guys. This is stuff I'd never figure out on my own so I really really appreciate it. But please be reminded that changing ISP is really the very very last solution that I'll choose. Even though it might be the most logical solution.

<3 / andeh

Try toggling the various options with Qizmo compression, and have the repeat packets on both ways. Generally the "quality mode" should be off with packetlossy connection.

There's pretty good net monitoring stuff in ezQuake -> cvarlist_re net

I also wanna try this stuff, dont wanna play eql playoff with this shitty PL
If it stays this way i'll switch ISP but dont have time for that in the middle of the playoff i guess.

So that's settled then - we upgrade quake to use ICMP instead of UDP.

Alternatively it could be due to packet rates.
Maybe their router considers the many small ~20 byte packets that QW clients send to be a distributed denial of service attack on their routers.
Either that or they want to fuck over media streaming in order to promote their own services, and quake gets hit in the crossfire.
Fiddle with your cl_c2spps cvar. Try it with a value of 20 or 30 (will make quakeworld look more like other games, but will increase your ping).
r_netgraph will show a visual display of your packetloss/ping. Maybe it'll be random, maybe there'll be some pattern.

This should probably also be said in here. Packets in UDP can be delivered out of order.

For example if the server sends packets 1,2,3,4,5,6,7 and the client will receive packets 1,2,3,5,4,6,7. When the QW client receives packet 5, it will announce packet 4 was lost. Then it will receive packet 4, but it's already too late and it will be discarded. I've been playing with netcat today and found out this is the case for our ISP, packets get reordered. When I run hrping with -s 13 I can see that the ping is quite jumpy - from 7 to 33 ms. Packets get delivered, but in different times. The ping utility, unlike qw client, does wait for packets to be delivered, no matter the order.

So when I earlier said I can't measure any packetloss with icmp ping, I now know how to measure it:
hrping -s 13 -w 13 -o <address>
This indeed shows similar packetloss rate as QW.

This also explains why Qizmo packet repeating did not work for me.

Summary: Your ISP might not be losing any UDP packets, it is just delivering them in slightly altered order, might be due to jumpy ping.
Solution: AFAIK, none.
Idea: add something into the client, similar to cl_delay_packet, that'd buffer incoming packets for a few msecs and fix the ordering. It'd increase the ping, but would make PL go away and perhaps would be able to stabilize the ping a little.

And finally, there's /showdrop and /showpackets to determine what's happening with the packets, if they are really re-ordered or just lost. Just found out mine are simply lost ..

The thing about buffering packets JohnNy_cz is really interesting.

Medar and I were talking about it like half a year ago regarding cl_early_packets 1, that it isn't as smooth as using delay_packet and having min/avg/max the same. Medar wrote some code to buffer the packets use the highest ping you got with earlypackets to make the packet handling more smooth. Should be investigated more I think!

Guys,
Couldnt rate help here? Maximizing packet size to be sent could reduce PL (and of course increase ping), isn`t it?

I get PL even if I do nothing on the server and incoming packet rate is 1.7 kB/s. So no, rate cannot help me.
"Maximizing packet size to be sent" - no idea what you are talking about...