htdvisser
(Hylke Visser)
December 22, 2017, 9:58am
36
There have not been any changes in the scheduling logic since we doubled the time-before-tx on March 10 2016 (1bb19bf818
). After reading the discussion here (and on Twitter) I just added another 200ms (c8bd97b135
) to increase support for slow connections (or slow gateways). I’ll try to have that change deployed later today.
This is definitely not true. In the future we may give application owners the option to prefer authenticated/secure gateways (using MQTT or gRPC over TLS) over unauthenticated/insecure gateways (using JSON over UDP), but that won’t be enabled by default.
The MQTT server in between indeed adds a bit of delay. We’re working hard on reducing this by optimizing our MQTT server. Right now the extra delay is a few milliseconds at worst.
Of course TCP may also add some extra delay on bad connections (TCP packets are retransmitted, whereas UDP packets would simply get lost)
7 Likes
jmarcelino
(Jose Marcelino)
December 22, 2017, 10:08am
37
Wow this is like the best Xmas present from TTN I could ever hope (yes even better than the TTN gateway Thank you so much @htdvisser
Yes I think much of the overhead is on packet generation on the client side. But very good to know you’re on top of the server!
4 Likes
Verkehrsrot
(Verkehrsrot)
December 22, 2017, 12:26pm
38
I still have the “too late” error with the MatchX Gateway.
Fri Dec 22 12:24:29 2017 daemon.info syslog[1428]:
INFO: Received pkt from mote: D000742B (fcnt=46037)
Fri Dec 22 12:24:29 2017 daemon.info syslog[1428]:
JSON up: {“rxpk”:[{“tmst”:2204454315,“time”:“2017-12-22T12:24:28.961510Z”,“tmms”:1197980687961,“chan”:2,“rfch”:1,“freq”:868.500000,“stat”:1,“modu”:“LORA”,“datr”:“SF7BW125”,“codr”:“4/5”,“lsnr”:7.0,“rssi”:-47,“size”:23,“data”:“ACt0ANB+1bNwA+EbAAujBACLA2K81Hg=”}]}
Fri Dec 22 12:24:30 2017 daemon.info syslog[1428]: INFO: [down] PULL_ACK received in 49 ms
Fri Dec 22 12:24:34 2017 daemon.info syslog[1428]: INFO: [down] PULL_RESP received - token[182:216] : )
Fri Dec 22 12:24:34 2017 daemon.info syslog[1428]:
JSON down: {“txpk”:{“imme”:false,“tmst”:2209454315,“freq”:868.5,“rfch”:0,“powe”:14,“modu”:“LORA”,“datr”:“SF7BW125”,“codr”:“4/5”,“ipol”:true,“size”:33,“ncrc”:true,“data”:“IHrmg/62xh41zRa0XrvdYkBYcgohzAzbMejsCECNSLGH”}}
Fri Dec 22 12:24:34 2017 daemon.debug syslog[1428]: src/jitqueue.c:233:jit_enqueue(): ERROR: Packet REJECTED, already too late to send it (current=2208964645, packet=2209454315, type=0)
Fri Dec 22 12:24:34 2017 daemon.info syslog[1428]: ERROR: Packet REJECTED (jit error=1)
Fri Dec 22 12:24:40 2017 daemon.info syslog[1428]: INFO: [down] PULL_ACK received in 49 ms
moeterbln
(Thomas Graf)
December 22, 2017, 12:28pm
39
What firmware version is shown in the MatchX cloud interface for your gateway? I think that runs the old firmware.
arjanvanb
(Arjan)
December 22, 2017, 12:29pm
40
Is there any way for people to see which backend version is active?
(I don’t think Releases · TheThingsArchive/ttn · GitHub tells us?)
Verkehrsrot
(Verkehrsrot)
December 22, 2017, 12:29pm
41
Still 0.0.3, and there is no update offered in eux.matchx.io
moeterbln
(Thomas Graf)
December 22, 2017, 12:31pm
42
I didn’t choose a update myself. They pushed it to 0.0.4 without notifying me after the long discussions. I think you have to contact them on all channels to make them react.
arjanvanb
(Arjan)
December 22, 2017, 12:34pm
43
So, if TTN indeed did not make any changes that caused the problems: any chance MatchX changed the firmware first without all of you knowing that?
moeterbln
(Thomas Graf)
December 22, 2017, 12:37pm
44
That is possible and the usual way they seem to act. Unfortunally you don’t have the chance to really know that. You have to believe the firmware version that is displayed.
I won’t expect them to acknowledge any bug that is found to be their fault. By definition it seems that only TTN can be the bad guy.
htdvisser
(Hylke Visser)
December 22, 2017, 12:55pm
45
You can get the deployed versions from the discovery server using ttnctl discover [router/broker/handler]
:
ID ADDRESS VERSION PUBLIC
== ======= ======= ======
meshed-router thethings.meshed.com.au:1901 v2.9.0-0c455d496d... true
switch-router ttn.opennetworkinfrastructure.org... v2.9.0-0c455d496d... true
ttn-router-asia-se asia-se.thethings.network:1901 v2.9.1-8477a84c83... true
ttn-router-brazil brazil.thethings.network:1901 v2.9.1-8477a84c83... true
ttn-router-eu eu.thethings.network:1901 v2.9.1-8477a84c83... true
ttn-router-jp router.thethingsnetwork.jp:1901 v2.9.0-dev-e4cb53... true
ttn-router-us-west us-west.thethings.network:1901 v2.9.1-8477a84c83... true
v2.9.1
contains the 200ms extra time for slow gateways or gateways on a slow connection
2 Likes
moeterbln
(Thomas Graf)
December 22, 2017, 12:57pm
47
Does that include earlier delivery of Join Accept messages to the gateway?
gatewayer
(Gatewayer)
December 22, 2017, 12:58pm
48
You have no idea what you are talking about Informed people pushing nonsense, do you even “tech” dude?
htdvisser
(Hylke Visser)
December 22, 2017, 1:02pm
49
gatewayer:
The changes were 100% made by TTN, TTN stated they changed it
You can see the history of our scheduling code on github .
Yes, all downlink messages should arrive at the gateway earlier now.
3 Likes
htdvisser
(Hylke Visser)
December 22, 2017, 1:02pm
50
This is not how we talk to our fellow community members here, @gatewayer . Please treat people with respect. Consider this an official warning.
6 Likes
arjanvanb
(Arjan)
December 22, 2017, 1:03pm
52
To make thinks clear: @gatewayer works at MatchX. If it weren’t for @htdvisser ’s reply I’d have blocked you right away.
arjanvanb
(Arjan)
December 22, 2017, 1:07pm
54
Aaron aka @gatewayer , I’ve already PM’d you that I’m afraid that suspending you will just feed your rants, but don’t think we’ll not do that anyway.*
Some way to treat your customers, wow.
*) guess what, I suspended you after all, after your PM, and after deleting some of your product “recommendations”:
But let’s end this conversation, I feel it’s slowly coming down to your level and I don’t want to go to those depths.