> On Oct 17, 2017, at 7:18 PM, Dave Täht <[email protected]> wrote:
> I tried rust out at about the same time esr did (in fact, sped up his go code
> by threading it better). Didn't like it, either.
>
> ( http://esr.ibiblio.org/?p=7294 <http://esr.ibiblio.org/?p=7294> )
>
> Honestly, I don't know what to do about having better R/T capable code in a
> better language. All I can do is point out things like temporarily disabling
> garbage collection as means of getting closer, promoting cpus that could
> context switch better, and buying old cars that don't have bluetooth support.
>
Interesting commentary- not into bluetooth? :)
I like Go’s focus on code readability, because it makes coding more fun. A few
things I don’t love about it: that there are multiple ways to declare
variables, that I seem to spend more time plumbing enums than I want to, that
some of the standard libs are a little bare bones. But for me there’s more to
like than not. For some things though, I don’t know if anything will replace
good ‘ole C before the machines take over.
Also, to summarize the plan for upstream/downtream packet loss differentiation
in IRTT, in case there are any tips or better ideas.
The server will add two things to its replies, when requested in the
negotiation:
1) A uint32 for each client connection that counts the total number of packets
the server has received for that connection
2) A uint64 for each client connection containing a bitfield of the received
status of the last 64 seqnos, so that:
- The LSB always represents the latest received seqno
- When a new packet comes in, this number get left shifted by the number of
seqnos since the last seqno was received
- The number is returned to the client in every response, and the client
simply stores it for each round trip during the test
- When the test is over, the client uses these numbers to re-create which
packets the server received and which it didn’t
- The “received” status for each round-trip in the results would then be one
of these four values, loosely:
- Received
- Lost upstream
- Lost downstream
- Lost unknown
If more than 64 server replies are lost in succession, you lose per-packet
differentiation of where the loss occurred, and it falls back to the total
count and "lost unknown," but at least the total server received count is still
there, which I don’t think is too bad. On the plus side, the client and server
don’t have to process or store much during the test, it’s a small addition to
the packet overall, and the client does most of the work reassembling the
received state after the test is done.
I should also probably return both these numbers in the connection close reply,
to make sure the client ends up with the latest values at the end of the test.
Otherwise, I can’t think of a way to make it “perfect” without storing results
on the server, which I’d like to avoid.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/tohojo/flent/issues/106#issuecomment-337347348_______________________________________________
Flent-users mailing list
[email protected]
http://flent.org/mailman/listinfo/flent-users_flent.org
