Measuring new default StarBeam speeds with tooltips.

[Sammysupport]

Hello,

in a setting with a local W32 SSL-Listener and a server W64-Non-SSL-Listener two Linux Laptops chat in a 1:1 window and transfer an installer-file of 43 MB.

The default pulse size of 30.000 leads to 39 KB/s and stalles sometimes. If the pulse size is set to 200.000, the speed is at 198 KB/s. If the pulse size is set to 1.000.000, the speed is at 980 KB/s. If the pulse size is set to 1.500.000, the speed is at 1,43 MBit/s.

The read intervall set from 2,500 sec to 1,000 sec seems not to influence the speed, probably the time ETA. Fast machines can handle 1,000 - which means to read every second.

Please provide the read interval with only one digit after the comma: "1,0" or "2,5" and provide a default at "1,0". Please provide instead the Percentage with 2 digits after the comma: 90,34 %, to make more progress viewable. Please provide also a default for the pulse size of at lease 1.500.000? to reach in any case "MBit/s"

(In case the values are set to a "stalled ETA" a balancing algorithm could start the upload again with half values (of pulse and interval) for the next 10 sendouts etc. ? There could be an auto- testing in optimization of pulse sizes and shorter intervals..?)

Please provide a tooltip for the transfered and received files tabs in StarBeam with the following values:

- Pulse Size: 1.700.000 (Default)
- Read Interval: 1.0 (Default)
- Total Filesize: 43.123.123
- Transferred: 38.123.123
- Percentage received: 90,34 %
- EST Time: 3 Min.
- Status: Transferring  
- Current Speed: 1,5 Mbit/s

this tooltip could be also available in the 1:1-Chat-Window?

Thanks, regards Sam

[textbrowser]

Too high. The default size is appropriate for wireless, lane widths, and friendliness. Is modifiable so not a problem.

[textbrowser]

You're allowed to set a pulse size afterwards and it may improve the transfer or damage it because everything is asynchronous and the pulse size is required by a receiver. All is there for non-automatic algorithms and for people to decide best.

[textbrowser]

E-TCP or the EchoTCP is rate-adaptive. It isn't size adaptive. So you set a size and an interval and it attempts to adhere to the calculated rate. Sometimes it'll exceed and sometimes it won't. Many, many variations in a true network.

[textbrowser]

E-TCP is a software-layer protocol for reliable program-program exchange.

[Sammysupport]

what about a E-TCP handshake as in Ultra-StarBeams to adjust/adapt on both sides to max rate of minimal chain member?

[textbrowser]

You're too busy thinking of a best solution without actually exchanging information. That's your proposal. Busy work.

[textbrowser]

And then when the algorithm thinks that it has a best solution, that solution is poorer than what the person configured. So, the best solution cannot be lesser than that solution but you can't decide that unless you're always measuring. You spend more time measuring without any benefit.

[textbrowser]

We is know what we do and because we is not always correct, we let people decide. Algorithms made by people or machines are not best.

[textbrowser]

0.255 is a valid interval. So, leaving.

[textbrowser]

Percentages are now as rationals. Rates are now as rationals. Tool tips will be evaluated later and ignored because they do not work well in volatile places. Best for statics.

Algorithmic improvements to busted environments bust up the instructions in Spot-On and introduce nonsense. If a stall occurs in the 15-second frame, an algorithm will not improve the delay. There's a horrible accident on the highway. You need to create an improved algorithm to escape that highway. I'm 30 miles from the next exit. I can exit here in this magical forest and arrive at my destination. Now arriving in 30 days. Nonsense in this fabricated magical thinking.

[textbrowser]

Incorrect conclusion regarding read interval. Let's compare.

[textbrowser]

Default followed by 0.125.

[textbrowser]

https://github.com/textbrowser/spot-on/assets/10701156/b9a5c9cf-3152-4131-aac3-b4cdaec7ecce

[textbrowser]

https://github.com/textbrowser/spot-on/assets/10701156/18d4556f-e6ca-4e05-9833-e634a74a3dd9

[textbrowser]

Dedicated systems have redundant networks. If a network is faulty, we go live to the backup. We look at the tarnished one while we live data. We don't scratch heads and go duh while data is lost. We scratch and go duh while the redundant is functional. We don't say well we need best algorithmic algorithm in life to speed up busted wireless and busted wire. Yah, on planet duh we do that.

[textbrowser]

That why in hospitals there be generators. And we have backup pens and laptops have batteries and we have batteries. Things to faulty and we have actual material solutions. The best solution is another material solution not an idea which may or may not improve the results. If idea, then it must materialize into function. Not just words of balancing juggling clowns. You got one wire and it feeds the entire toilet enterprise. Now you make wire smart with balance. Well, boss, why don't we just tell people to flush between time0 and time1 on floor 1 and time2 and time3 on floor 2. No, we balance the feces with balancing act. But boss. Balance the shit!

[textbrowser]

So now more requests to balance sewage. We let TCP fly and we let Echo fly on the flyer. Both materialize into their own local scopes while being suave agents of it-just-works. Spot-On has neighbors and if you have two wires, you can connect to those neighbors on two wires. So can get more data assuming your system can read more data. So many variables. But there it is if you look and sit and go hmmm.

[Sammysupport]

minutes(s) ?

suggest to to write the speed first and then time: ETA: 7.32 KiB/s (21.41 Minute(s)) or ETA: 7.32 KiB/s | 21.41 Minute(s).

Thanks.