xpra icon
Bug tracker and wiki

Opened 4 years ago

Last modified 4 weeks ago

#401 assigned enhancement

detect bad connection and warn the user

Reported by: Antoine Martin Owned by: Antoine Martin
Priority: minor Milestone: 2.2
Component: core Version:
Keywords: Cc:

Description

When we encounter network problems, we currently deal with it by lowering the framerate (sometimes too much) and drawing spinners on top of the windows.
In some cases, the user might be tempted to blame xpra when in fact it is the network that is the problem, so we should warn the user instead and tell them where to look for the problem.


Here is an obvious symptom:

window[3].batch.damage-packet-queue-size=(375, 1002)

Where we just can't send the packets out.


We should probably wait a little while to see if the network problem resolves itself rather than spamming the user. And make it an option? (or just tune the sensitivity? someone on 3G may care a lot less about notifications than when on a LAN)

Change History (9)

comment:1 Changed 4 years ago by Antoine Martin

Milestone: 0.110.12
Owner: changed from Antoine Martin to Antoine Martin
Status: newassigned

too late for 0.11

comment:2 Changed 3 years ago by Antoine Martin

Milestone: 0.120.13

see #540 for a more general ticket, re-scheduling.

comment:3 Changed 3 years ago by Antoine Martin

Milestone: 0.130.14

re-scheduling.

comment:4 Changed 2 years ago by Antoine Martin

Milestone: 0.150.17

re-scheduling.

comment:5 Changed 16 months ago by Antoine Martin

See also #999.

comment:6 Changed 11 months ago by Antoine Martin

Milestone: 0.173.0

comment:7 Changed 6 months ago by Antoine Martin

Milestone: 3.02.1

comment:8 Changed 6 weeks ago by Antoine Martin

Milestone: 2.12.2

re-scheduling

comment:9 Changed 4 weeks ago by Antoine Martin

Some ideas:

  • split min delay and optimal delay for calculations, near min != near optimal
  • fix send speed ratio calculations causing batch delay problems: should be a global thing, not per window
  • new factor: packet queue data size (not pixels, but compressed size)
  • don't recalculate if no of frames elapsed is low: counter<V
  • auto-refresh should take latency into account more (killing us over bad connection?)
  • target_latency used for a lot of things... jitter makes it bad, 20ms hardcoded - need better
  • #417 max-bandwidth switch server side: integrate in speed/quality calculations, batch delay for others: "target bitrate mode"
  • very small compressed frames: use this as hint that we can raise quality
  • higher latency: use more strict optimistic sending? take ack time into account: latency*2 + decode time = max time it should take and take packet size into account
  • min delay: higher when video region active so rgb paints can get joined in there?
Note: See TracTickets for help on using tickets.