r_netgraph should show out of order packets and everything.

I thought rate is command that defines how big data packets `move` between the server and the client. For example when I am conneting to a server and not having the map the server is using curently, my download speed can be increase (to a certain level of course) if I increase my rate.
This is why I had the idea, if we decrease the `traffic` with rate, maybe this lowered admount of traffic could arrive `properly`, without pl.



In the last week I`ve changed my ISP. Now I have UPC (in the Netherlands). This new one sucks. Same stuff as Andeh, constant PL, juming ping.

So I tested myslef the `rate` idea and saw it is not going to help. Probably it was stupid idea at all, as rate dows something else.

I also tested everything else that was mentioned here, without helping my PL:
-tcpconnect between local and remote qizmo
-cl_physfps

Did the hrping test and got PL with that tool also.

Checked /showdrop and I also see droped packets.


I would like to test the tcpconnection directly to a server. Could someone give me a server where tcpconnection is available?

update: found a server where I can connect with tcpconnect, but tcpconnetion generates more PL. I can see more packets dropped if using tcpconnect, so I guess my problem is a bit different, as I have more trouble with tcp traffic.

another thing: when I am spectator, I have 1-3%PL only.

cl_physfps_spectator...

I spent the last couple of days with testing, but I think I have no idea what is going on. I try to summarize what did I test. Maybe with this someone can help me out.
Basically my PL ratio is jamping from 0 to 25%, no matter what I do or try. I think it is related on the traffic of my ISP, as things go better at late night or in the morning, and worse at night.

What I`ve tried:
- simple connect to a server
- tcpconnect first to a remote proxy, then from this proxy to a server
- connect to a local proxy, then tcpconnect to a remote proxy, then to a server
- connect to a local proxy, then to a server
- played around with cl_phyfps

None of them realy helped. So I guess it is not only related to UDP traffic, as tcpconnect haven`t helped.

Monday there is a mechanic comming from the ISP to do some test on my connection. How could I prove him that the problem is related to their connection, as I haven`t have PL at all when I used a different (and much slower connection ) line from a different provider?


I will post some traceroute, tracert and hrping results too.

After I moved and got a new ISP, I also had problems similar to whats mentioned here.

Since I got a "technician" over here earlier today, and he basically told me everything was fine, I decided to look around a bit myself and see if I could figure something out. One page that was really informative and helpful, and eventually had the tip that somewhat solved my packet loss problems, was this:

http://homepage.ntlworld.com/robin.d.h.walker/cmtips/loss.html

Heres what I did to solve my problem:

- Open a browser, and type in 192.168.100.1 (which is the default ip for most cable modems afaik)
- Open the 'Configuration' menu on the left side
- In the 'Upstream Channel ID' I changed the value from '1' to '2' (apparently, valid numbers are 1-6)
- Save changes, and restart modem

The pl was down from a stable 10-20%+ to a quite stable 0, with a few jumps to 1-3 here and there. I can live with that!

I don't know whetever this info is helpful to others, or if it is a permanent solution since I've only tested it for one day, but it could at least be worth a shot if you got a cable connection and are experiencing issues with packet loss when playing QW.

(My theory: Upstream Channel ID 1 comes as default, and every single modem my ISP has delivered are using this channel. This channel gets overloaded with increased traffic on the cable line, which are typical for evenings when people get home from work etc. Therefore basically every other channel than the default could work, since they got little or no load on them currently.)