is it possible to bond (aggregate) multiple connections over GPRS (usb stick) and use it as one link in linux?
It is technically possible. Linux has a module called bonding which can assemble several interfaces into one logical interface. If you set the mode of the bonding interface to balance-rr, it will distribute the packets between the two interfaces. You will also need a server somewhere to reassemble the traffic that will come from your two links.
However, in practice the results with such setups are awful, especially with high latency and high jitter links like GPRS. The main reason is that you get a lot of out of order delivery and protocols like TCP become crazy in these conditions. So the resulting throughput will never reach the total throughput of the two links.
Related
I would like to communicate over USB using COAP protocol.
I am currently planning to use libcoap, it has examples but it is based on UDP server-client.
If I want to use USB, what must be done?
Thanks
Depends a bit on the deployment scenario, but in general I'd recommend using USB Ethernet inbetween (CDC-ECM). Then you can use CoAP over USB like you use it over any other network connection. (If you use RIOT for your embedded device and build the gcoap example on a board with native USB and enable the usbus_cdc_ecm module, you get that almost out of the box).
The large downside of this approach is that you are subject to the whims of the host OS's network setup. Probably it'll take up at least the IPv6 link-local interface so you can go ahead with requests to fe80::addr:ess (or even use link-local multicast to find your device), but there may be pitfalls.
There is the slipmux proposal which would do CoAP over serial, but a) I don't know implementations thereof, and b) it leaves you with similar issues of how to make sure your application can really find the right serial port.
It wouldn't be impossible to specify CoAP over custom USB commands (which would then be taken up by an application), but there'd need to be really good reasons not to just go through USB networking to justify them, and I'm not sure that the complexity of ensuring that your NetworkManager is set up correctly counts.
I am looking for some hints to build a network packet splitter. What i want is some sort of tools/code that split the packets of a logic link (tcp/ip connection for ex.) over several network interfaces.
I used with success the Linux bonding driver, however the best performance is only achieved when the bandwidth/latency of the several network interfaces is similar, since the bonding driver uses round robin packet splitting.
Anyone know any tool that can effectively split packets (not logical links) over network interfaces using a weighted manner, instead of round robin manner?
You can use sysfs to change your bonding mode to a more effective choice for your setup.
/sys/class/net/bond0/bonding/mode
You may have some luck also changing the queue_id in the same place to make different adapters more important.
Take a look at the Linux bonding documentation for information about the settings.
I am working on fpga firmware, in which i want to have very fast data transfer using ethernet . I got help from FPGA forum they say that suggest designs for data transfer using light weight internet protocol (LWIP).
How this is different from transfering the data using NDIS. I will be grateful if you can suggest me some guide to interface my visual c++ application to the network guide and tranfer the data.
many greeting in advance.
LWIP is a library for talking IP on a network.
NDIS is a specification for how an OS talks to network cards.
Neither is necessarily what you appear to want.
If you want to transfer data very simply and quickly point-to-point using Ethernet, you need to understand how Ethernet works at the packet level, and form your data into some Ethernet packets. You can make up your own protocol for this if you have control over both ends of the link.
If you want to transfer the data over an existing network topology, you would be better doing it using an existing protocol. UDP/IP might be one such protocol, depending on your requirements for data-rate, latency, software complexity, reliability etc. LWIP is one library which implements UDP, so might be of use.
I am writing a Linux device driver which supports multiple devices. I have a x8 PCIe card with 4 of these devices on it. Each runs through a PCIe switch and gets 2 PCIe lanes. Is there a way to have the driver write to multiple lanes at the same time? If so, how would I do this? I would think it should be possible since it is all on one PCIe slot, but I have no idea how this would be done from the driver.
PCIe doesn't work quite the way you think it does. The switch is not partitioning up the upstream x8 link into multiple x2 links -- it simply forwards traffic from one link to another. So what you will see is a x8 link to the switch, and then 4 x2 links from the switch to the downstream devices. However with a different switch and different downstream devices, it would be equally possible to (for example) have x8 links everywhere, ie a x8 link from the root port to the switch and x8 links from the switch to the downstream devices.
However, in your case you have a matched amount of bandwidth on both sides of the switch, so there should be no issue with devices competing for a limited amount of bandwidth. Your driver can talk to all the devices simultaneously as efficiently as if there were independent links.
It sounds like you're looking for PCIe multicast. This has no connection to the number of lanes, but would simply be a function of delivering a single write to multiple destinations as efficiently as possible. There is a standard for this, mostly intended for backplane uses, see: http://www.pcisig.com/developers/main/training_materials/get_document?doc_id=12f5c260ccf5e054366d4c96ee655fa6827db5b3
It looks like this is supported with a new PCI BAR type, where multiple devices would have the same mapped physical address range, and the switch would also be configured to know about this multicast range. But this all needs OS support, and I haven't found anything on the web to suggest that Linux has the pieces necessary to configure the devices to do all this.
Since your parent link has enough bandwidth to saturate all four child links, you don't have a throughput problem. The only thing you'd save with multicast is bandwidth from the memory subsystem. If you have a modern architecture, the amount you'd save would be in the noise.
In other words, don't worry about it. Treat your devices as independent (this will make for a cleaner driver, anyway) and get on with your project.
My colleague and I are mining the GPRS MODEM market for a module suitable for use with embedded Linux. During the market scan, we see that several vendors highlight that their MODEMs include an embedded TCP/IP stack.
This makes me wonder: when we are using embedded Linux which already contains a TCP/IP stack and connects using PPP, will it make use of the stack included in the GPRS MODEM at all?
My current assumption is that the stack is included for use with tiny microcontroller OS that do not supply their own stack. Also some of the MODEMs allow for running small applications IN the MODEM baseband processor which could explain the embedded stack...
So: is the TCP/IP stack supplied by the GPRS MODEM superfluous when using it with an HL OS or did I overlook something?
It is almost certainly superfluous in your use case.
Most cellular modem products are cut-down versions of products designed for use in mobile phones. Obviously, in a phone application, the TCP/IP stack is required, along with a whole pile of other functionality.
A typical GPRS modem probably contains an ARM9 processor, and this is not greatly taxted running just the modem software. For many smaller applications it certainly provides sufficient performance to run the entire application (think of something like a vending machine indicating that it is nearly empty, for example), and a TCP/IP stack might be helpful here.
There is a slightly cynical possible explanation, too. Many mobile phone stacks have a bit more software coupling than their manufacturers would like to admit to, and it may turn out that it is simply not worth the effort to remove the TCP/IP stack.
In your application, it is almost certainly the best option to use the AT command interface (this is an extension of old-fashioned dial-up modem command set to allow you to fetch information such as signal strength, network status etc.
This is the EXACTLY same question I been asking myself these two days. ^^
After some study and asking around, I found this:
In the case of a smart phone such iPhone/android, TCP/IP are running on Application Processors(AP) as part of the OS. Baseband Processors(BP) are simply network modems (think of the 56k dial-up modem and PC setup in ancient time). Of course BP will be running mobile network stack(GSM, CDMA, LTE...) to hop on cellular network, but to AP, it's transparent and simply does modulation/demodulation work for the wireless network. Modems receives AT commands and can switch between command mode and data mode in operations. In data mode, the protocol between AP and BP is normally PPP over serial (! correct me if i am wrong here). So TCP/IP/PPP/serial.
Embedded TCP/IP stack found in some BP are meant to provide an entire abstraction for certain applications whereby network stack is not available due to system constraints or simply made to be simple. A TCP/IP stack is then very useful in BP. As you mentioned, some BP (e.g infenion) does have extra processing power for user application and/or network stack. AP, in this case, is even not needed. This is a typical setup of a function phone(such as Nokia brick). Extension of AT command sets are then provided by BP to create a socket or even a FTP connection.