Devices support LoRaWAN 1.0.3 and 1.1 specifications with OTAA and ABP activation methods. Gateways support BasicStation and Semtech UDP packet forwarding when communicating with designated Network Servers.
You should never ever run large scale tests against the community network as that will impact the community. If you want to test use your own private deployment!
@johan@htdvisser what is your take on the YouTube video and the suggestion the software can be used to test the scalability of the network server just after a demo using the community network?
I think it’s pretty harmless on a small scale. At some point, various rate limiters will start to kick in. What’s mostly heavy is connecting many gateways in a short time frame so that is throttled. Also if you have hundreds of gateways with the same originating IP address, that will hit rate limiters too. See Rate Limiting | The Things Stack for LoRaWAN
I don’t think this is useful for The Things Stack Community Edition or Cloud. I mean, the scalability has already been proven for 99% of the practical use cases. We provision resources on expected demand so spikes caused by artificial load testing is not being appreciated.
It may be useful for an on-prem The Things Stack Open Source and Enterprise to see how it behaves under load and to predict how many resourced are required. To that end, I’d prefer not mentioning The Things Network in this video but The Things Stack Open Source and Enterprise.
Would it be OK if we came over to your place of work with some rebar and tried a load test on your local electricity supply? Or use a pickaxe on your water main to see what the response time is for the repair company to get your supply back on?
I’m not even sure I understand the idea behind simulating devices that use UDP to pass packets to your simulated gateway - why not just have a generator?
I’d say welcome to the forum, but it’s like a Biker Crew gate crashed a Sweet Sixteen party.
The video showing 1 gateway and 2 sensors communicating with The Things Network was only meant to show interoperability with it.
Yes, sorry for inadvertently suggesting that the simulator be used to test scalability of a community network, which would be a very bad idea.
The utility of the simulator lies in its ability to assist the development, demonstration and testing of application software prior to actually deploying hundreds of real LoRa sensors and gateways. It can also be used to make sure that the on-prem hardware used for deploying Network and Application servers are appropriate.
Yes, it can be used to make sure that the on-prem hardware used for deploying Network and Application servers are appropriate. We have changed the YouTube video title to use Stack instead of Network.
The video showing 1 gateway and 2 sensors communicating with The Things Network was only meant to show interoperability with it.
Sorry for inadvertently suggesting that the simulator be used to test scalability of a community network, which would be a very bad idea.
Unlike a simple packet generator, each simulated sensor is capable of generating varying payload using scripting and encoding/decoding packets using the associated Network and Application keys.
The utility of the simulator lies in its ability to assist the development, demonstration and testing of application software prior to actually deploying hundreds of real LoRa sensors and gateways. It can also be used to make sure that the on-prem hardware used for deploying Network and Application servers is appropriate.
Thanks for welcoming us to the forum as we think this solution can add value to the LoRa eco-system, and sorry for starting on a bad note.
Does it correctly parse and act on / respond appropriately to all legal MAC commands in downlinks?
If it doesn’t, it’s not LoRaWAN.
And that, in addition to being a fundamental conflict of purpose, would be yet another reason it should never be pointed at TTN servers.
If you’re not running an actual RF gateway receiving public traffic from the airwaves on behalf of the the TTN community, don’t point at TTN servers! Spin up a private instance for your games.
Please don’t copy & paste the same reply, we do see all the responses in the thread.
I think not.
If I want to test my back end I can setup software to flood the web hooks / MQTT etc as required. My failover using Data Storage is tested by emulating the Data Storage API, given it’s simplicity and that also saves unnecessarily pumping large amounts of data through my TTS OS.
This is a very appropriate use case and once the dust has settled on this little faux-pas, I may look in to it. I think we can take it from the use of TTS CE that is currently processing 450+ messages a second and delivering 100+ messages a second, that it’s got some legs, so we don’t need to test that. But as indicated above, to truly test the capacity of an install, that is the hardware sizing & placement, fail-over etc, the device simulator would have to be able to respond to MAC commands if you were testing the removal or addition of a simulated gateway &/or altering RF reception profiles. This seems to be implied in the blurb but not really detailed.
PS, if you can compile for Linux & Windows, what happened to macOS?
PSS, tech people hate going to their bosses for budget requests without any indicative pricing.
So you left what’s actually the hardest part of LoRaWAN compliance for the user to sort out on their own. And a “device” that’s not compliant will trigger unending responses from a private instance of TTS.
Just sending and receiving packets is an afternoon’s work in python.
One would almost be in a better shape taking something that already works in those respects like LoRaMAC node and crosscompling it to run as a process or thread. Especially as a queue based message passing scheme that timestamps downlinks would eliminate any need to actually catch them in real time.
Our sales folks can give you more details.