Good work everyone,
I am communicating with the STM32F746 processor using the lwip library. I got the ethernet buffers in the special area of the RAM and protected it with the MPU. Then I disabled the buffering feature. My code works as I want, but after 10-15 minutes communication is cut off. My grounding, my connections, everything looks good.
I left the mpu protection as default (0x30000000).
I wrote the following in the flash.ld file
. = ABSOLUTE(0x20010000);
*(.RxDecripSection)
. = ABSOLUTE(0x20010080);
*(.TxDecripSection)
. = ABSOLUTE(0x20010100);
*(.RxArraySection)
. = ABSOLUTE(0x200118D0);
*(.TxArraySection)
I set memory region from ethernetif.c file. But the result is still the same. My connection drops after 10 minutes.
Related
I've been trying to run this simple tcp congestion analysis script that I wrote.
The topology is a 2 source node dumbell topology with a bottleneck in the center.
Something like
n2 n4
\ /
n0-----n1
/ \
n3 n5
The dashed line has a bandwidth of 100 Mbps ( 1ms. delay ) and the solid line has a bandwidth 60Mbps (2.5 ms delay)
The bottleneck has a DropTail queue in place with max no. of packets = 2084p.
This configuration will lead to congestion and the congestion window getting reducecd at around 1sec as shown in the file streams cwndDropTail_1/0.txt
Now, I want to to plot the number of packets dropped vs time in the bottleneck link (n0 - n1).
For this I used TraceSources as shown in lines 62-70 in tcp_ftp_n.cc. like so
...
Config::ConnectWithoutContext("/NodeList/*/DeviceList/*/$ns3::PointToPointNetDevice/TxQueue/Drop", MakeBoundCallback(&RxDrop, dropped_stream));
Config::ConnectWithoutContext("/NodeList/*/DeviceList/*/$ns3::PointToPointNetDevice/TxQueue/DropAfterDequeue", MakeBoundCallback(&RxDrop, dropped_stream));
Config::ConnectWithoutContext("/NodeList/*/DeviceList/*/$ns3::PointToPointNetDevice/TxQueue/DropBeforeEnqueue", MakeBoundCallback(&RxDrop, dropped_stream));
Config::ConnectWithoutContext("/NodeList/*/DeviceList/*/$ns3::PointToPointNetDevice/PhyRxDrop", MakeBoundCallback(&RxDrop, dropped_stream));
Config::ConnectWithoutContext("/NodeList/*/DeviceList/*/$ns3::PointToPointNetDevice/PhyTxDrop", MakeBoundCallback(&RxDrop, dropped_stream));
But none of these are able to trigger the callback RxDrop that writes into the file stream droppedPacketTrace.txt in spite of the fact that I can see the queue getting completely filled and the congestion window being reduced at the source.
What am I doing wrong here?
I did read a thread on the internet where it said that when a queue is filled, the packets are no longer dropped from the queue but simply never "enqueued". Does this have something to do with my problem, and if so then how should I proceed?
I tried being as detailed as possible but please inform me if you need some extra insight into the setup. I am attaching all the required files.
link for the codefile - tcp_ftp_n.cc
https://drive.google.com/file/d/15DvhYWEDNvpnZqAAgjM9Tq6oUeVsgw8X/view?usp=sharing
Note - I run ns3-dev
I have a rather busy RabbitMQ setup which at peak times becomes extremely slow accepting new connections (RabbitMQ 3.9.14)
I've tried fine tuning /etc/sysctl.conf as found on a guide on the RabbitMQ website
fs.file-max = 10000000
fs.nr_open = 10000000
fs.inotify.max_user_watches=524288
net.core.somaxconn = 4096
net.ipv4.tcp_fin_timeout = 30
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_keepalive_time=30
net.ipv4.tcp_keepalive_intvl=10
net.ipv4.tcp_keepalive_probes=4
net.ipv4.ip_local_port_range = 10000 64000
net.ipv6.conf.all.disable_ipv6=1
net.ipv6.conf.default.disable_ipv6=1
net.ipv6.conf.lo.disable_ipv6=1
net.netfilter.nf_conntrack_max=1048576
And also played around with the rabbitmq.conf options to see if anything would have an impact, however that is unfortunately not the case
num_acceptors.tcp = 32
channel_max = 4096
tcp_listen_options.backlog = 512
tcp_listen_options.nodelay = true
tcp_listen_options.linger.on = true
tcp_listen_options.linger.timeout = 0
tcp_listen_options.sndbuf = 196608
tcp_listen_options.recbuf = 196608
collect_statistics_interval = 60000
Due to the nature of my setup (PHP), every time messages are being published to RabbitMQ, a new connection is created, I wish I could do long-standing connections but that is beyond of what PHP is designed for
During peak activity, some connections take up to 7 seconds to open, once the connection is established however, the messages publishing performance is just fine.
I feel like I've exhausted all the logical options that I'm aware of. Is there any other tweaks that I can attempt to change in order to improve the connection performance of the node? The server load is low-ish, sitting at 15% peak. Disabling the management interface had negligible impact
Update: At first, when I've updated to RabbitMQ 3.10.5, I thought that the issue was solved, however that was not the case, it just gave us a bit more headroom.
The real cause was our high churn-rate (200/s+), during my conversation in the RabbitMQ slack channel it became apparent that a high churn rate would block the event loop and cause the spikes seen above.
The solution for us was to use a proxy to re-use connections instead of opening a new one every time we publish something:
https://github.com/cloudamqp/amqproxy
This has effectively resolved our issue.
I try to get my SIM7070G Cat-M/NB-IoT/GPRS HAT running with micropython on a ESP32 MC via UART. Unfortunately I did not find any libraries but I thought this can not be too difficult with micropython. I am working on this problem now for 3 days and do not get any response when sending commands with uart.
USB with computer:
Sending AT commands gives an answer like sending AT and receiving OK.
Micropython:
from machine import UART
from time import sleep
sleep(1)
print("activate")
p = Pin(27, Pin.OUT, Pin.PULL_UP)
sleep(0.1)
p.on()
sleep(1)
p.off()
sleep(0.5)
print("activated")
uart = UART(1, 115200,rx=9,tx=10,timeout=5000)
#uart.init(9600, bits=8, parity=None,rx=25,tx=26,stop=1)
uart.write(b'AT\r\n')
print("uart.write(b'AT\r\n')")
sleep(1)
data = uart.any()
print(str(data))
I just do not get a response. data is always 0.
What I tried:
checked connection 100 times, TX->RX and RX->TX, 5V, GND, PWR
different pins did not work
different baudrate... no difference.
Anyone a solution? That would be really great.
Link to manufacturer of SIM7070G HAT
I figured out the solution. As #hcheung sais, I have to call AT command a few times (up until 10 times) to let the module get the baudrate. It will work than properly.
I have a VW Golf 4, which is quite old and talks KWP 2000 (ISO 9141) on its CAN bus. I use a dongle powered by ELM 327, connected to the OBD-2 port of the car.
I am trying to send messages individually to each ECU. I tried to change the header of the messages:
AT SH 48 XX F1 (I hoped XX would be the ECU ID; 48 is the flag for "use physical addressing"). Any command I issue (e.g. tried 3E for "tester present") returns NO DATA (I disabled automatic timeouts and set the timeout to maximum value).
Is there a way to send messages directly to the ECU? I am not interested in the set of data provided via OBD-2, neither do I want to re-flash the ECUs. At the moment I just try to find out which ECUs are available on the bus.
Thanks!
VW works on Transport Protocol TP 2.0, hence you need to initialize with 0x200 header.
https://jazdw.net/tp20
See above link for more info.
I'm building an embedded device with a couple of sensors. The device will 'stream' digital data from these sensors over Bluetooth or USB.
Most of the communication will be from the embedded device to the host. The host will infrequently be sending control messages, to control the gain etc.
Since the physical and data link layers are taken care of, I'm looking for a simple message protocol that will make it easy to develop user applications to process/display data on the host computer. Does anyone have any suggestions?
A simple text protocol may be the best for this application.
Use the communication channel as a bi-directional serial pipe.
The device can stream sensor values in ASCII (text) format, separated by commas, with each set separated by the newline character. The rate is preferably set by the host.
For example,
21204,32014 (new line character '\n' - 0x0A) at the end of each line
21203,32014
21202,32011
....
This makes it easier to test, to stream the values to a file, import in to a spreadsheet etc.
Similarly commands to the device too, is best done in text.
SET GAIN_1 2 ( sent by host )
OK ( reply by device )
SET GAIN_2 4 (sent by host )
OK ( reply by device )
SET GAIN_9 2 (sent by host )
ERROR ( reply by device if it does not understand)
SET RATE 500 ( set the sensor dump rate to every 500 ms )
OK