-
Notifications
You must be signed in to change notification settings - Fork 1
/
progressmeetingnotes.txt
56 lines (47 loc) · 3.05 KB
/
progressmeetingnotes.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
Progress update:
Ping instability still an issue
-> Problem is smaller when bi-directional ping/other traffic on the network
-> Not entirely gone: flood, pc to pc over 60ghz
262199 packets transmitted, 262198 received, 0,00038139% packet loss, time 1604663ms
rtt min/avg/max/mdev = 0.636/7.178/338.796/8.660 ms, pipe 22, ipg/ewma 6.120/8.177 ms
--> If we assume the use-case is a non-realtime VR implementation e.g. displaying prerendered video, we can probably simply mitigate this with a frame buffer.
--> The lag becomes a terrible UX issue in realtime applications though (e.g. VR gaming)
Throughput assymetry also still an issue - probably a talon hardware issue?
Also an issue when iperfing talon->talon.
T1 and T2 = talons.
T1 AP, T1 iperf server: ~1.3 Gbps
T1 AP, T2 iperf server: ~1.0 Gbps
T2 AP, T1 iperf server: ~1.3 Gbps
T2 AP, T2 iperf server: ~1.0 Gbps
Achievable throughput iperf, at last test: Slightly over 400 Mbit, PC to PC. Roughly 95 Mbit over my lan (currently 100 Mbps)
This results in a resolution
Application layer:
UDP process, TCP process, NTP process + main thread handling communication between the processes (slightly simpler implementation than having a pipe for every process pair)
Udp roughly implemented
NTP is also basically ready but needs to be integrated.
TCP should control/send statistics about UDP, currently UDP does not yet report required statistics to make it relevant
Requirements:
Stable video transmission with reasonable packet loss.
loss < 0.5% seems like a good goal, though lower is always better
Video resolution that we can transmit, in current testing case, is directly related to both desired frame rate and video resolution.
Calculation in previous slides was wrong. Current PC -> PC speeds definitely insufficient to support that video spec though.
Other option:
HP Reverb : 2160x2160, 90 Hz, 114° FoV
Resolution requirement: 180/114 * 2160 vertical
360/114 * 2160 horizontal
= 6820 * 3410
6820*3410 / (7680*4320) = ~0.7 (0.70096088927) = (23256200 / 33177600)
--> Compute file size as a percentage of the 8k VR video included in Maria's zip
90Hz = *3
--> Adjust for framerate. Given probable better compression on video (more temporal redundancy), this most likely overestimates
==> 26.1224489796 MB/s * (23256200 / 33177600) * 3 = ~55 MBps
5.5e7 Bps --> Probably still not ok for pc->pc (high-end was around ~500Mbps (~= 4e7 Bps)
Maria video:
Encode each frame as jpeg, no temporal redundancy
Makes data requirement a lot higher.
Current implementation is compression agnostic - simply has equal frame sizes for all frames, so sending as jpg is fine
But viable resolution will be rather low, probably
Logging later:
NTP for time sync allowing near exact time match between machines
(LAN link allows sub-millisecond accuracy, in my testing roughly within 100 us)
-> Should allow for reported timing results to be fairly accurate and allow us to draw conclusions about latency