Im experimenting two net cameras on the AMPRNET
One is http streaming the other is RTSP streaming
The http uses tcp port 80
the rtsp uses udp (dont remember the port now )
The http replace photo every 250 MS (i assume after it get ACK and then send the next image) ( i see about 4 frames per second) and make a traffic of about 1000 kbit/sec
the RTSP send photos in about 10 frames per second and produce traffic of about 500-800 Kbit sec
all this over the amprNet
May someone explain this ? how come that the RTSP photo is like movie and the http is 4 frames per second (of course that if i view the http camera direct on the net i see the 10 frames per second i set the camera for)
And why i tell you all of this ?
Because i wonder how a DMR repeater connection will work on the amprNet ...
If i can see in RTSP video without problems or frame loss should a VOIP (or more exact) data stream of the DMR work ? after all it is less data ....
Is there anyone that can light my eyes on the subject ?
Regards
Ronen - 4Z4ZQ
Ronen,
Let me understand...
Where is the client located (what country)?
If the client is in Israel (IL), their Syn packet:
- Leaves the Public IP in IL and goes to AMPRGW in California - Is encapsulated and leaves California for your tunnel in IL with an IPENCAP header - You encapsulate a reply with a Syn-Ack to the client, it leaves IL for California - it is de-encapsulated and sent from California to the client Public in IL
Can you provide ping and/or traceroute results to the host IP and AMPRGW?
- Lynwood KB3VWG
raceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 60 byte packets 1 haifa-gateway.ampr.org (44.138.1.1) 2.265 ms 3.428 ms 3.612 ms 2 amprgw.ucsd.edu (169.228.34.84) 223.616 ms 223.700 ms 224.116 ms 3 169.228.34.82 (169.228.34.82) 223.709 ms 223.769 ms 223.827 ms 4 nodem-core-6807-vlan3095-gw1.ucsd.edu (132.239.254.178) 224.024 ms 224.313 ms 224.034 ms 5 mx0--nodem-core-30ge.ucsd.edu (132.239.254.162) 225.623 ms 224.858 ms 225.431 ms 6 dc-sdg-agg4--ucsd-1.cenic.net (137.164.23.53) 225.580 ms 221.851 ms 227.612 ms 7 dc-tus-agg3--sdg-agg4-100ge.cenic.net (137.164.11.8) 230.205 ms 232.388 ms 232.430 ms 8 dc-lax-agg6--tus-agg3-100ge.cenic.net (137.164.11.6) 232.583 ms 233.134 ms 232.597 ms 9 74.125.49.165 (74.125.49.165) 233.025 ms 233.196 ms 233.231 ms 10 108.170.247.129 (108.170.247.129) 230.802 ms 108.170.247.193 (108.170.247.193) 230.915 ms 108.170.247.225 (108.170.247.225) 230.006 ms 11 216.239.62.107 (216.239.62.107) 230.663 ms 209.85.250.209 (209.85.250.209) 231.031 ms 209.85.255.185 (209.85.255.185) 230.880 ms 12 google-public-dns-a.google.com (8.8.8.8) 223.838 ms 221.134 ms 225.461 ms
traceroute to 44.138.1.39 (44.138.1.39), 30 hops max, 60 byte packets 1 cslab254.cs.aueb.gr (195.251.248.254) 0.349 ms 0.337 ms 0.322 ms 2 aueb-2-gw.kolettir.access-link.grnet.gr (62.217.98.202) 1.753 ms 1.741 ms 1.702 ms 3 eier-kolettir-AE.backbone.grnet.gr (62.217.100.63) 3.868 ms 2.188 ms 2.190 ms 4 grnet.mx2.ath.gr.geant.net (62.40.124.89) 2.280 ms 2.276 ms 2.303 ms 5 ae1.mx1.ath.gr.geant.net (62.40.112.215) 2.216 ms 2.153 ms 2.196 ms 6 ae2.mx1.mil2.it.geant.net (62.40.98.150) 58.934 ms 59.062 ms 59.054 ms 7 ae4.mx1.gen.ch.geant.net (62.40.98.88) 65.838 ms 65.979 ms 65.968 ms 8 ae4.mx1.par.fr.geant.net (62.40.98.152) 73.110 ms 73.221 ms 73.233 ms 9 ae1.mx1.lon2.uk.geant.net (62.40.98.76) 79.800 ms 79.822 ms 79.797 ms 10 ae3.mx1.lon.uk.geant.net.geant.net (62.40.98.78) 80.649 ms 80.531 ms 80.646 ms 11 internet2-gw.mx1.lon.uk.geant.net (62.40.124.45) 155.343 ms 155.213 ms 155.095 ms 12 et-9-0-0.4079.sdn-sw.ashb.net.internet2.edu (162.252.70.66) 156.321 ms 156.117 ms 156.074 ms 13 et-7-1-0.4079.rtsw.chic.net.internet2.edu (162.252.70.61) 172.747 ms 172.737 ms 172.741 ms 14 et-3-1-0.4070.rtsw.kans.net.internet2.edu (198.71.47.207) 183.787 ms 183.786 ms 183.784 ms 15 et-8-0-0.4079.sdn-sw.denv.net.internet2.edu (162.252.70.10) 194.194 ms 194.171 ms 194.188 ms 16 et-4-1-0.4079.rtsw.salt.net.internet2.edu (162.252.70.9) 203.731 ms 203.721 ms 203.640 ms 17 et-7-0-0.4079.sdn-sw.lasv.net.internet2.edu (162.252.70.30) 211.179 ms 211.166 ms 211.173 ms 18 et-4-1-0.4079.rtsw.losa.net.internet2.edu (162.252.70.29) 215.813 ms 215.739 ms 215.809 ms 19 137.164.26.200 (137.164.26.200) 215.716 ms 215.832 ms 215.794 ms 20 hpr-lax-agg6--lax-hpr.cenic.net (137.164.26.246) 216.179 ms lax-agg6--lax-hpr3-100g.cenic.net (137.164.26.208) 216.345 ms hpr-lax-agg6--lax-hpr.cenic.net (137.164.26.246) 216.276 ms 21 dc-tus-agg3--lax-agg6-100ge.cenic.net (137.164.11.7) 217.252 ms 217.176 ms 217.290 ms 22 dc-sdg-agg4--tus-agg3-100ge.cenic.net (137.164.11.9) 219.896 ms 219.867 ms 220.044 ms 23 dc-ucsd-1--sdg-agg4.cenic.net (137.164.23.54) 218.271 ms 218.414 ms 218.621 ms 24 nodem-core-6807-vlan2767-gw.ucsd.edu (132.239.254.61) 218.356 ms 218.317 ms 218.289 ms 25 ebu3b-6509-nodem-core-interconnect-vl910-bcast-255-131.ucsd.edu (132.239.255.131) 218.581 ms 220.736 ms 220.770 ms 26 * * * 27 4z4zq-pi.ampr.org (44.138.1.39) 445.361 ms 441.295 ms 441.300 ms
________________________________ From: 44Net 44net-bounces+ronenp=hotmail.com@hamradio.ucsd.edu on behalf of lleachii--- via 44Net 44net@hamradio.ucsd.edu Sent: Sunday, May 28, 2017 12:07 PM To: 44net@hamradio.ucsd.edu Cc: lleachii@aol.com Subject: Re: [44net] Latency in various protocoles
(Please trim inclusions from previous messages) _______________________________________________ Ronen,
Let me understand...
Where is the client located (what country)?
If the client is in Israel (IL), their Syn packet:
- Leaves the Public IP in IL and goes to AMPRGW in California - Is encapsulated and leaves California for your tunnel in IL with an IPENCAP header - You encapsulate a reply with a Syn-Ack to the client, it leaves IL for California - it is de-encapsulated and sent from California to the client Public in IL
Can you provide ping and/or traceroute results to the host IP and AMPRGW?
- Lynwood KB3VWG
_________________________________________ 44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net
Ronen,
The traceroute to 8.8.8.8 provides no information.
If the second tracerote you provided was from the client, this helps.
As you can see, a round trip is almost a half a second. In essence, it takes one second (or more) for you to request and receive a frame from your camera. With UDP, there is no confirmation of packet receipt (though I thought RTSP used tcp/1935, but the requesting and receipt of packet are different). If the frame requires multiple packets, this becomes exponential on HTTP, since each likely requires the standard connections and HTTP GET request.
Simply put, 4 frames a second is probably the best quality over AMPRNet (from the client's location) for accessing the HTTP camera stream. You must use a streaming-type protocol. Your open TCP connections may also be timing-out somewhere along the path.
- Lynwood KB3VWG
-
lleachii＠aol.com -
R P