|
|
|
Member 950 posts
Registered: Apr 2006
How do I change it to be more than 9kBs?
Member 151 posts
Registered: Jan 2006
sv_maxdownloadrate "100000" at server rate 100000 at client kill me now and burn my soul
Member 950 posts
Registered: Apr 2006
Thx Is that bytes or bits /s? Is there a limit? Are there consequences on games playing if bandwidth is 100Mbs?
Administrator 2058 posts
Registered: Jan 2006
bytes per second
100 000 = 100kb/s
Member 1026 posts
Registered: Feb 2006
correction: 100 000 = 97.65625 kB/s
Member 129 posts
Registered: Mar 2006
I was downloading maps on xs4all ffa when i was in with flepser, he told me to type "setinfo drate 999999" the map downloaded in seconds...
Administrator 2058 posts
Registered: Jan 2006
correction: 100 000 = 97.65625 kB/s correction: 100000 = 100 kB/s 102400 = 100 KiB/s
Member 950 posts
Registered: Apr 2006
Administrator 2058 posts
Registered: Jan 2006
?
server setting: sv_maxdownloadrate "100000"
client setting: /setinfo drate 100000
that's it
Member 271 posts
Registered: Feb 2006
The drate solution given above is the only solution commonly available to the user. The rest of this post concerns the quake network protocol and attempted improvements.
Download speeds in quake are dependant upon ping and framerate. Assuming that you have totally unlimited drate, you'll get about 768*framerate bytes per second assuming you have no ping at all. This scales downwards as your ping increases. At a frame time of 13 seconds (74fps), and a ping of 26, you've probably lost two thirds of your download speed. A ping of 52 and you've only got a fifth left. A higher drate cannot stop this ping-based degredation. This is why an insanly high drate will not give you insanly fast downloads.
Why? The download bits of the quake network protocol are 'reliable'. This means that the server keeps spamming the same bit of data over and over again to the client until the client acknoledges it, and it sends the next bit of data only when the server receives a request for the next bit. You end up with a sequence where the server waits for the client to acknoledge the data, and for the reliable buffer to be empty enough to send the next chunk. One waiting for the other means that there's not much data going most of the time, and there's a lot of duplicated data too.
In FTE I sought to resolve this issue. Instead of having the server wait for the client to ask for the next chunk, I redesigned it to have the client constantly spam requests for chunks in an unreliable way. The client responds with the requested chunk instead of simply the next chunk. Each time the client has requested 64 different chunks, it re-asks the server for any missing chunks (otherwise packetloss would destroy the data). This means that the client is in charge of which bits of the file are downloaded - it's possible to resume downloads. The data is only resent if it's actually dropped, instead of spammed until acknoledged, and ping times do not affect download rate.
The result is a more bandwidth efficient download, a much higher max download rate, and the 56k users not sitting around getting bored whilst everyone else is already in game. Because it's built in to fte's extension system, the old network protocols are used when playing through qizmo/cheapo, and there are no compatability issues.
I would very much aprechiate it if this system (or even a similar one) was used in other clients and servers (that means you, mvdsv and ezquake people). Come on. Get cracking.
Member 950 posts
Registered: Apr 2006
That sure would be nice Thanks for the explanation!
Moderator 1329 posts
Registered: Apr 2006
correction: 100 000 = 97.65625 kB/s correction: 100000 = 100 kB/s 102400 = 100 KiB/s Aquashark was actually right. Using oldschool measurements, only transfer rates with bits are calculated that way. Meaning 10Mbps = 10 000 000 bits per second while 10MB/s = 10485760 bytes per second. Almost all windows and *nix software use 1024 as a multiplier in calculating transfer rates (exception: ms ftp.exe ). Only very few software use KiB/s even now, only one I've seen so far is bittornado. Also when talking about storage, kilobytes and megabytes always use multipliers of 1024. With the exception of cheap hard drive manufacturers that have marked their hd's sizes incorrectly for 20 years now (I still remember time when 20MB hard drive was actually 20MB (20*1024^2 instead of 20*1000^2). Most of the software calculate sizes like this nowadays, too.
Administrator 2058 posts
Registered: Jan 2006
this discussion is retarded anyway, so let's just stop here
you win the grand prize
Member 810 posts
Registered: Jan 1970
This is not retarded at all, in fact it's very important. One bit is the smallest amount of information in computers. It can either be 0 or 1. It's normally written as 2^0 = 1. Two bits are written as 2^1 = 2 and three bits are written as 2^2 (which is 4 btw). Now comes the Byte which is the smallest amount of memory a normal pc can access. It has the size of 8 bits. And 8 bits are written as 2^3 = 8. Computers are different to physics. In physics a kilo would mean 10^3. Like one tonne is 1*10^3 kilos (at least in europe). That's not the case in computers. One kilo in computer terms is 2^10 = 1024 and one mega in computer term is 2^20 = 1048576. Soooo what's the big deal about it? If people say they have a 100 mega-bit / sec connection they acctually mean they can transfer up to 100 * 2^20 bits/sec. But most isps do not speak in computer terms. As transmitting data over wires involves a lot of physics they might as well switch to the physics notation of kilos, megas and gigas. That's why you might see round numbers in isp ads. -> Most data transfers are measured in bits / sec either in physics or computer notation. Most software will use the computer notation. Memory should always be measuerd in bytes and computer notation. If you read this far you see.. there is a _big_ difference between B and b and too many people don't have a fucking clue )
Member 47 posts
Registered: Jan 2006
sv_maxdownloadrate "100000" at server rate 100000 at client probably useless information but.. someone (i think zu-zu) told me that max rate is 65535.
|
|
|
|