05-15-2016, 11:18 PM
@PabloDons, I could see if there is some way to speed up already fast downloads, but the current implemention has problems with high speed. I could readjust it, but benefits are still questionable. I'll explain the problem later. The lower your highest ping amount is, the more benefit you get from this. Average ping won't work with this formula, unless your ping is consistently average. 1000/(2*ping)= bits saved per second in the worst case scenario. So a ping of 50ms can download 10 bits per second in addition to whatever you download normally. Technically you can get more than 10 bits but I would need to do a ton of fiddling and tweaking, which in my guess you would get 40 bits per second if lucky. Now that I say it that way, it might not be worth it xD.
Anyway, assuming that the amount you download is consistent (probly not), you could choose when to send packets to save bits. Delaying packets in this example by your ping amount will mean you download the same amount at the end of the second (probly not the case IRL).
Every X bytes of data received, a bit will be saved too, depending on WHEN the packet is received. In the 50ms example, every 50ms means to toggle the value of the "register" bit (0->1->0). Once a bit is saved, it won't be changed, but the register still keeps toggling, saving more bits later on.
I guess saving 10-40 bits per second wouldn't be very ground breaking for someone with a 3Mb/s download or higher though. The whole thing relies on low ping, low speed connections, which is almost never the case. Usually someone has high-low or low-high.
The idea has had a long journey away from what it originally was. It started with me wondering if there was someway to convert satellite video on two ends into digital data, then receive a little bit of data to find a huge chunk of data. But cutting out the satellite video as a middle man proved that its not very efficient.
This new idea is the best I've got so far, 10-40 bits/second... assuming it works and you get lucky. So polish it some more, or drop it and look somewhere else?
Anyway, assuming that the amount you download is consistent (probly not), you could choose when to send packets to save bits. Delaying packets in this example by your ping amount will mean you download the same amount at the end of the second (probly not the case IRL).
Every X bytes of data received, a bit will be saved too, depending on WHEN the packet is received. In the 50ms example, every 50ms means to toggle the value of the "register" bit (0->1->0). Once a bit is saved, it won't be changed, but the register still keeps toggling, saving more bits later on.
I guess saving 10-40 bits per second wouldn't be very ground breaking for someone with a 3Mb/s download or higher though. The whole thing relies on low ping, low speed connections, which is almost never the case. Usually someone has high-low or low-high.
The idea has had a long journey away from what it originally was. It started with me wondering if there was someway to convert satellite video on two ends into digital data, then receive a little bit of data to find a huge chunk of data. But cutting out the satellite video as a middle man proved that its not very efficient.
This new idea is the best I've got so far, 10-40 bits/second... assuming it works and you get lucky. So polish it some more, or drop it and look somewhere else?