You could say this mod was born out of necessity: my ISP is the fastest and cheapest one around... the catch is that it's got quotas...
- 2001: 1GB up at 128kbps, 6GB down at 3.1Mbps, $20/GB uncapped surcharge.
- 2002: upload quota increased to 5GB and I went a 'little' over-board with downloads, got a $500 bill. Ouch.
- Jan. 2003: $5/month price hike accompanied by an upstream bandwidth increase to 180kbps (+32kbps), download quota increased to 10GB (+4GB), surcharge dropped to $8/GB (from $20/GB) and capped to $100 (from unlimited), now this is a lot more sane and the upload speed is just about enough to make downloading from two torrents at once viable.
- July 2003: upstream bandwidth increased to 320kbps, download quota increased to 15GB, surcharge capped to $30 - some of the local competition has gone quota-free... if the competition does not turn about, the quotas should increase again (or disappear) after enough customers complain or threaten to switch ISP. They did remove quotas on their "Extreme" but it still costs nearly twice as much as standard service.
- April 2004: After another $3/month hike in February, another upgrade to the package... download bandwidth increased from 3.1Mbps to 4.2Mbps, upload and download quotas both increased by 5GB. This $3/month hike packs quite a bit more value than the previous $5/month one.
- So the current state of affairs is... (at it should be at some moment around April)
- 10GB upload quota at 320kbps (maybe this will be upgraded but that would be mostly irrelevant since I rarely manage more than 240-280kbps)
- 20GB download quota at 4.2Mbps
- $8/GB surcharge capped to $30
- $38 CAN/month (increased by $8 since 1997)
- Why I haven't ditched it yet? Well...
- it is still among the least expensive
- I do not feel like switching ISP for temporary benefits because of temporary issues
- I do not really need to download much more than 10GB in a typical month and with the latest quota upgrade, I expect to have more slack than I will care to use.
- With the latest download speed upgrade, it is by far the fastest for the money
- High-speed (>2Mbps) DSL service is not available
- Even if it were, the cheapest package would still be at least $10/month more
- The cheapest DSL available (1-1.5Mbps) is about 1/3 as fast but costs just as much
Because using the most of my download quota means I have to avoid running up my upload quota for nothing, I needed something to help me bias my UL:DL ratio towards whatever my ISP is offering... this means 1:3 today but used to mean 1:6 (practically no upload allowed since most of it was being consumed by overhead) in 2000-2001.
- [2003-10-29] After further considering how preferences should be handled, I decided to merge the core and GUI again... but in a much cleaner manner than the original merged implementation.
- [2003-09-30] While re-applying UDReg to eMule 0.30b, I decided to split it in two classes a little like everything else is... one class implements the functionality, the other the GUI. I also re-arrange the way UDReg configuration data is handled to make it more self-contained and reduce its footprint in existing code.
The first "version" was on eDonkey... a simple binary hack that changed the ratios for <10KB/sec to 1:10 000... this way, I could manually change my upload and download speeds to any value I had to set it to in order to re-establish my quota's balance. With only 1GB up, this usually meant 0.25KB up and unlimited down.
When eDonkey started including spyware, I decided to ditch it and use eMule... but eMule used integers to store its values and finding constant integers is far more burdensome than finding floats. The second 'version' was to manually set upload and download speeds because I did not have VisualStudio at the time and no time to mess with it either. With the 5GB up and 6GB down ratio at the time, setting the upload speed at 1-4KB/sec when I could not babysit was good enough.
Then I got VisualStudio at around the same time the download quota was increased to 10GB... if I ended up setting upload speed to 1KB/sec no matter how fast downloads were going, I would get nowhere slow. The babysitting approach was clearly not suitable so I started modding... and the third 'version' was to remove the "don't be a lam3r" code so I could set the download speed independently of upload speed, manually adjusting upload speed to compensate for how well/bad they have been since the last time I checked.
At this time, talks about the credit system were all over the place so I thought I should make my client look roughly as fair as the regular ratio system would usually allow, thinking someone might write something to detect clients that are too far out of line... so I decided to make my upload speed adjust dynamically to the download speed but with a filter/delay to avoid boosting/reducing limits on spikes. The first version was a simple IIR filter with hard-coded coefficients... (the current implementation still uses pretty much the same code)
lastdownrate=theApp.downloadqueue->GetDatarate();
lastuprate=theApp.uploadqueue->GetDatarate();
float lastdownratef = lastdownrate / 1024.0;
if (lastdownratef > hystdown) {
hystup = hystdown/4 * 0.05 + hystup * 0.95;
hystdown = lastdownratef * 0.15 + hystdown * 0.85;
} else {
hystup = hystdown/4 * 0.10 + hystup * 0.90;
hystdown = lastdownratef * 0.05 + hystdown * 0.95;
}
uint16 newuprate = ceil(hystup + 0.01);
uint16 newdownrate = ceil((hystdown + 2)/3)*3;
if (newuprate >= 10) newuprate = 10;
theApp.glob_prefs->SetMaxUpload(newuprate);
theApp.glob_prefs->SetMaxDownload(newdownrate);
But after a few attemps at tuning this filter, doing this hard-coded soon prooved to be extremely inconvenient and time-consuming...
- Requires a recompile for each attempt (3-4 minutes)
- Must wait for downloads to become active (??? minutes)
- The client gets banned for hammering, which further increases the wait time to getting remotely decent speeds.
At this point, I quickly patched together a simple GUI which eventually lead to its current form in What does it look like?
The Upload:Download regulator is built into Moonlight's Mod (Latest build: 0.30e-0.22f, 2003-12-15).
A picture is worth a thousand words
- Bandwidth filter's response time. The higher the value, the more time it will take UDReg to react to changing UL and DL speeds. Internally, those values are converted to become the 'alpha' value for a simple filter of the following form: Y = Yz^(-1)*a + X*(1-a)... a simple first-order IIR filter.
- Enable/disable the speed regulators. Disabling the regulator sets your current speed to the Maximum speed specified below in #3.
- These let you set the baseline UL/DL speeds along with the absolute maximum UL/DL speeds. I created this mod so I could upload without busting my quota while receiving nothing. With the UL regulator enabled, set your Max UL speed to ~80% of your actual wire speed, the minimum UL speed to whatever speed you are willing to share at all times and let the ratios in #4 boost your UL speed from Min up to Max proportionally to your actual DL speed.
- The ratios and ratio thresholds let you adjust how much of a UL boost you are willing to give for each KB/sec of actual DL speed you manage to get.
- The newer UDReg version has a button in the lower right to open the filter coefficient monitoring window.
This is how my graphs typically looked like with eMule 0.30a:
Typical low-speed rollercoaster.
The maximum download speed is locked at 150KB/sec, a little pointless since I have not seen peak download speeds over 100KB/sec on eMule/eDonkey in over a year.
- Note:
- UDReg overrides the limits settings in the "Connection" Preferences pannel when their respective regulators are enabled.
Hits since December 5, 2003:
Generated on Sat Feb 7 00:52:25 2004 for Moonlight's eMule Hacks by
1.3.4