• 0 Posts
  • 21 Comments
Joined 1 year ago
cake
Cake day: June 7th, 2023

help-circle










  • non-moving home devices

    There still is a use case - not that common in America but very common in (not only Europe’s) metropolitan areas:

    If the devices are located in a dense urban residential area (say Berlin Gropiusstadt in the 11th of 20 floors) you have a lot of neighbors with wifi, and - at least on 2.5GHz - roughly a third of their wifis will use the same or overlapping frequency range. In the evening, when everyone and her dog streams the newest Season of Bridgerton those will send relatively short bursts for buffering the next five-ish(?) minutes.

    This of course interferes with your measurement if you happen to measure at exactly the same time, so having multiple samples instead and providing an aggregated value is - for this scenario - more helpful.

    OTOH: it all depends on the use case of those appliances - if you don’t have competitive gamers who wonder why they sometimes lag in your valued customer list, that’s a non issue (and if they actual were competitive gamers, they should use an ethernet/fiber cable instead of wifi, obviously).

    And you probably did not get that much time allocated to add the delay, so going with another variant could get you in trouble if it’s taking too long.









  • 4-5 times now. When confronted with more than a hundred commits between latest known working version and the one you’ve observed the bug (which was not catched by any of the unit tests) it can save some time to find the fishy commit.

    In such a case I create a testcase on top to reproduce the bug. Then bisect and for each stage add the testcase, build, run tests. FYI: this only works if all (or at least most) of the commits in the chain are compilable - if you’ve done a big messy refactoring with several commits breaking the build, bisect can get you only so far.