Related
So i started making test streams on my youtube channel using Streamlabs OBS.
I turned on performance mode, looked at the stream but it was like 2 fps.
I looked at task manager and my network usage was NEVER going past 1%, and streamlabs's network usage rarely went past 0.1 mbps.
This happens with other things too, and i don't like it since it makes my internet so slow. Internet (if you're wondering): Verizon Fios 5Ghz connection.
The percentage simply shows the relation between the current network usage and the link speed of your network adapter. For example, if your link speed is 1 Gbps and you're transferring data at 10 Mbps, the network usage will be 1%.
When transferring data over the Internet, the percentage is generally not very useful, because the maximum speed is defined by your ISP and, in your case, is likely to be a lot lower than your adapter speed. Furthermore, your Internet speed can also be degraded by a poor Wi-Fi signal, by other users in the same network, etc.
What you should actually be looking at is the actual speed (in bit/s) at which you are sending data (look at the "Send" field in the performance tab of the task manager) and compare that to your Internet speed (which you can learn by doing a speed test).
I'm working on an engineering project where I want a go-kart to maintain a direct connection with a base station. The base and go-kart can be separated by about a half mile (with lots of obstacles in between) which is too far for WiFi.
I'm thinking about using 3G/4G to directly connect the two. Does anyone have any resources or ideas that might help?
Or, alternatively, a better way to connect them? I'm just trying to send some sensor data (pretty low bandwidth) in real-time.
The biggest problem you face is radio spectrum that you are allowed to use. All 3G/4G spectrum is licensed to some firm and they get really unhappy (e.g. have you hunted down and fined) when you transmit in their space.
I did find DASH7 which
is an open source wireless sensor networking standard … which operates in the 433 MHz unlicensed ISM band. DASH7 provides multi-year battery life, range of up to 2 km, indoor location with 1 meter accuracy, low latency for connecting with moving things, a very small open source protocol stack …
with a parts cost around US$ 10. This sounds like it satisfies your requirements and keeps the local constabulary from bothering you.
You could maybe use SMS, between a modem on the kart and a mobile phone or modem at the base.
A mobile data connection like a telephone call isn't possible directly between the two; you have to make a data connection from the kart to a server in your operator's core network, identified by the APN. Then you can access IP addresses as for a normal internet connection - so the base computer would have to be a web server.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
I had an Idea and I was wondering if it was possible. I've googled it and can't seem to find any existing solutions. I was thinking of having a Bluetooth mesh network. The layout I was hoping to achieve is to have one central station (PC with bluetooth dongle) and then a bunch of bluetooth modules (preferably these) that would all form a mesh network with the modules around them. Not all of them would be in range of the "central station" but would need to communicate with it through the other nodes. The bluetooth modules would be hooked up to ATtiny85 chips if it makes any difference. If you have any questions just ask.
Is this possible?
Is it possible with the above bluetooth module?
Would they all have to be set up individually or could there be some sort of neighbor discovery?
Would there be security risks?
What would the limitations on the size of the network be?
Where should I start?
CSR has delivered a BLE mesh network solution
http://www.csr.com/news/pr/2014/csr-mesh
Not sure if you have found a reasonable solution yet, I am new to the BLE and was also thinking along the same lines of having a BLE mesh that can permit transmitting of signal up to a few miles or so. This way, sensors can be placed in remote rural areas and utilizing multiple hops of sensors, the data can be transmitted to the central controlling station. However, as of yet, I haven't seen a dual mode sensor that can assume both roles as needed.
The other approach can be to make use of TCP/IP bridge. This way, the device, which can be an iPhone or Android, listens to the advertised data, creates an IP packet and send it to the remote server. Obviously, for this to work you need to have cellular data network available. But granting ubiquitous data network or Wi-Fi coverage this solution sounds more promising to me.
NOTE: Here http://www.bluetooth.com/Pages/low-energy-tech-info.aspx they talk about star topology though, below is the excerpt:
Topology – Bluetooth low energy technology uses a 32 bit access address on every packet for each slave, allowing billions of devices to be connected. The technology is optimized for one-to-one connections while allowing one-to-many connections using a star topology. With the use of quick connections and disconnections, data can move in a mesh-like topology without the complexities of maintaining a mesh network.
Also have a look at FruityMesh. It is an open source implementation of a mesh network that is based on standard Bluetooth Low Energy 4.1 connections.
They use the Nordic nRF51 chipset in combination with the S130 SoftDevice.
Found on github: https://github.com/mwaylabs/fruitymesh/wiki
So bluetooth - as clearly pointed out in the comments - is not designed for mesh networking. Nor, honestly would you want to. It would be far to expensive both in fincances AND in processing time and battery power to handle such an operation.
Instead, why not use XBee? https://www.sparkfun.com/search/results?term=xbee&what=products
These XBee modules are not only designed to do EXACTLY what you want, but they are low cost and HEAVILY documented.
A much better choice for your wifi mesh.
well, theoretically it should possible to build a mesh networking behavior with BLE devices, though it has not been designed that way.
The idea would be to use the fact that BLE has been designed so it can work over disconnections.
So you could handle two connections with your device: one as a bluetooth master and the other as a bluetooth slave. Then you could run once as a slave and listen to the next device's services see if there is any event, and if there is, become a master and broadcast the event to the previous device until the event reaches the host. The tricky part would be to tweak the timings so it works fastly and smoothly.
Another way that should be less a hack would be to build an ANT network for the mesh topology, while having BLE to be able to connect each node to Bluetooth enabled devices. You could use something like the nRF51422 to do such thing.
HTH
As I undertand, Bluetooth is something designed to do data transmission with a low power consumption. So compared to 802.15.4, Bluetooth shows a much shorter communication range which means more device maybe used to build a network. And I think BLE is just a name, just some code pre-programmed into chip ROM. Anyone can modify the BLE protocol, if he gets enough coding experience.
I am designing an iOS app for a customer who wants to allow real-time (with minimum lag, max 50ms) conversations between users (a sort of Teamspeak). The lag must be low because the audio can also be live music, played with instruments, so all the users need to synchronize. I need a server, which will request audio recordings to every client and send to others (and make them hear the same sound at the same time).
HTTP is easy to manage/implement and easy to scale, but very low-performing because an average HTTP request takes > 50ms... (with a mid-level hardware), so I was thinking of TCP/UDP connections kept open between clients and server.
But I have some questions:
If I develop the server in Python (using TwistedMatrix, for example), how are its performance ?
I can't develop the server in C++ because it is hard to manage (scalable) and to develop.
Anyone used Nodejs (which is easy to scale) to manage TCP/UDP connections?
If I use HTTP, will it be fast enough with Keep-Alive? Becuase usually the time required for an HTTP Request to be performed is > 50ms (because opening-closing connection is hard), and I want the total procedure to be less than that time.
The server will be running on a Linux machine.
And finally: which type of compression can you suggest me? I thought Ogg Vorbis would be nice, but if there's anything better (and can be used in iOS), I am open to changes.
Thank you,
Umar.
First off, you are not going to get sub 50 ms latency. Others have tried this. See for example http://ejamming.com/ a service that attempts to do what you are doing, but has a musically noticeable delay over the line and is therefore, in the ears of many, completely unusable. They use special routing techniques to get the latency as low as possible and last I heard their service doesn't work with some router configurations.
Secondly, what language you use on server probably doesn't make much difference, as the delay from client to server will be worse than any delay caused by your service, but if I understand your service correctly, you are going to need a lot of servers (or server threads) just relaying audio data between clients or doing some sort of minimal mixing. This is a small amount of work per connection, but a lot of connections, so you need something that can handle that. I would lean towards something like Java, Scala, or maybe Go. I could be wrong, but I don't think this is a good use-case for node, which, as I understand it, does not do multithreading well at this time. Also, don't poo-poo C++, scalable services have been built C++. You could also build the relay part of the service in C++ and the rest in whatever.
Third, when choosing a compression format, you'll have to choose one that can survive packet loss if you plan to use UDP, and I think UDP is the only way to go for this. I don't think vorbis is up to this task, but I could be wrong. Off the top of my head, I'm not sure of anything that works on the iPhone and is UDP friendly, but I'm sure there are lots of things. Speex is an example and is open-source. Not sure if the latency and quality meet your needs.
Finally, to be blunt, I think there are som other things you should research a bit more. eg. DNS is usually cached locally and not checked every http call (though it may depend on the system/library. At least most systems cache dns locally). Also, there is no such protocol as TCP/UDP. There is TCP/IP (sometimes just called TCP) and UDP/IP (sometimes just called UDP). You seem to refer to the two as if they are one. The difference is very important for what you are doing. For example, HTTP runs on top of TCP, not UDP, and UDP is considered "unreliable", but has less overhead, so it's good for streaming.
Edit: speex
What concerns the server, the request itself is not a bottleneck. I guess you have sufficient time to set up the connection, as it happens only in the beginning of the session. Therefore the protocol is not of much relevance.
But consider that HTTP is a stateless protocol and not suitable for audio streaming. There are a couple of real time streaming protocols you can choose from. All of them will work over TCP or UDP (e.g. use raw sockets), and there are plenty of implementations.
In your case, the bottleneck with latency is not the server but the network itself. The connection between an iOS device and a wireless access point (AP) eats up about 40ms if the AP is not misconfigured and connection is good. (ping your iPhone.) In total, you'd have a minimum of 80ms for the path iOS -> AP -> Server -> AP -> iOS. But it is difficult to keep that latency stable. (Typical latency of AirPlay on my local network is about 300ms.)
I think live music over iOS devices is not practicable today. Try skype between two iOS devices and look how close you can get to 50ms. I'd bet no one can do it significantly better, what concerns latency.
Update: New research result!
I have to revise my claims regarding the latency of wifi connections of the iDevice. Apparently when you first ping your device, latency will be bad. But if I ping again no later than 200ms after that, I see an average latency 2ms-3ms between AP and iDevice.
My interpretation is that if there is no communication between AP and iDevice for more than 200ms, the network adapter of the iDevice will go to a less responsive sleep mode, probably to save battery power.
So it seems, live music is within reach again... :-)
Update 2
The ping-interval required for keep alive of low latency apparently differs from device to device. The reported 200ms is for an 3rd gen. iPad. For my iPhone 4 it's more like 50ms.
While streaming audio you probably don't need to bother with this, as data is exchanged on a more frequent basis. In my own context, I have sparse communication between an iDevice and a server, but low latency is crucial. A keep alive therefore is the way to go.
Best, Peter
I'm currently in the process of performance profiling. We have a basic client/server application. Would the TCP transfer speed be different if I ran client/server on the same machine (localhost) vs across two computers on a LAN?
TCP transfer speed will be! because if you ran it on same computer it will forward packets locally without even touching LAN and network adapter.
But overall speed of client+server may be better on different machines, especially if you do not communicate with server too often.
When using localhost, local resources are more likely to be the performance bottleneck because of memory, disk, cpu, etc. When using two computers, its more likely the network will be the bottleneck because of latency, bandwidth, throughput, packet loss, etc.
It depends on what your application does and how it uses the network, client, and server.
Yes definitely, the latency of sending it across the network would slow the program down. The throughput wouldn't but if you're waiting for replies before sending data then this builds up because of extra latency.
I just hit this issue on a project at work. Using UDP with localhost is at least an order of magnitude faster than over a network connection (maybe two orders of magnitude), and I believe with localhost there is no MTU ceiling of 1500 as normally exists for network ports.
One unconfirmed suspicion is the built in network ports on PCs are not all the same quality, so even if they claim to be gigabit, you may not be able to really go that fast. But it may also be making lots of Windows system calls (one OS call per packet) may be a significant overhead. With TCP I can hand the OS a large chunk of data to write in a single call. With UDP I have to hand it a packet at a time, limited by the MTU size, resulting in a much larger number of OS calls. But unconfirmed as yet.
Have not tried Linux yet.
It really depends on what your application does....
As an example:
If it transfers 10GB files from client to server, then yes, it will make a difference.
I don't know if it measurable (that also depends on your LAN's speed) but from a logical point of view, of course there is a difference. Localhost will always be the fastest as the data has not be sent through another medium (like air or copper wire).
But depending on what your application does, this might or might not matter.
The transfer times would almost certainly be faster if the client and server were on the same machine. That may not actually matter to the performance of your program as a whole depending on the other resources consumed by the client and server.