I contributed that particular fix and have been using it in my code for several years. I had the same issue that on small networks the ARP cache was fine but once there were any more than one or two hosts on a network, the ARP cache was constantly churning and almost every network send required an ARP transaction on the network before it could complete.

It works very well for me and I've got some of my BACnet devices on networks with 700 or more other BACnet devices that send tons of broadcasts and they work fine.

Regards,
Peter

Tom,
I just saw your post. Thanks for this. I will give it a try.
Steve
From: "Tom Collins t...@tomlogic.com [rabbit-semi]"
To: r...
Sent: Monday, March 25, 2019 4:00 PM
Subject: Re: [rabbit-semi] ARP Table size

Steve,
You might also want to take a look at this commit that I never merged into master:
https://github.com/digidotcom/DCRabbit_10/commit/2fc3a5268ee8d8656694367b66a78463e6f1855d
I believe it addresses the issue you’re talking about, that the Rabbit adds ARP entries from broadcast traffic for device that it’s never going to communicate with. It was a significant change that I can’t thoroughly test, so it never made it into a release.
You could test it on the RCM6750, and if it works well, back port it to Dynamic C 9 for your R3k modules.
-Tom
On Mar 20, 2019, at 7:46 AM, s...@yahoo.com [rabbit-semi] wrote:
The reason I increased the ARP table is because of the way the R3k modules work. Every device on the network that they see, they add to the ARP table, printers, computers, oscilloscopes, mobile phones, etc. Even though the module will never communicate with any of them. So what happens is, when the table is full, the next addition bumps the oldest one off the table. Eventually, the device the module is communicating with get pushed off the ARP table. The TCP connection is lost and the host has to reconnect to re-establish communication. Many a customer has complained about this, so I increased the ARP table to 20, then 64, and now to 128. I've had no complaints about this with the R6k modules, but then there are many many more R3k modules fielded than R6k. But just in case, I increased the table to 128 on the Rk6 module.
#yiv0720018681 #yiv0720018681 -- #yiv0720018681ygrp-mkp {border:1px solid #d8d8d8;font-family:Arial;margin:10px 0;padding:0 10px;}#yiv0720018681 #yiv0720018681ygrp-mkp hr {border:1px solid #d8d8d8;}#yiv0720018681 #yiv0720018681ygrp-mkp #yiv0720018681hd {color:#628c2a;font-size:85%;font-weight:700;line-height:122%;margin:10px 0;}#yiv0720018681 #yiv0720018681ygrp-mkp #yiv0720018681ads {margin-bottom:10px;}#yiv0720018681 #yiv0720018681ygrp-mkp .yiv0720018681ad {padding:0 0;}#yiv0720018681 #yiv0720018681ygrp-mkp .yiv0720018681ad p {margin:0;}#yiv0720018681 #yiv0720018681ygrp-mkp .yiv0720018681ad a {color:#0000ff;text-decoration:none;}#yiv0720018681 #yiv0720018681ygrp-sponsor #yiv0720018681ygrp-lc {font-family:Arial;}#yiv0720018681 #yiv0720018681ygrp-sponsor #yiv0720018681ygrp-lc #yiv0720018681hd {margin:10px 0px;font-weight:700;font-size:78%;line-height:122%;}#yiv0720018681 #yiv0720018681ygrp-sponsor #yiv0720018681ygrp-lc .yiv0720018681ad {margin-bottom:10px;padding:0 0;}#yiv0720018681 #yiv0720018681actions {font-family:Verdana;font-size:11px;padding:10px 0;}#yiv0720018681 #yiv0720018681activity {background-color:#e0ecee;float:left;font-family:Verdana;font-size:10px;padding:10px;}#yiv0720018681 #yiv0720018681activity span {font-weight:700;}#yiv0720018681 #yiv0720018681activity span:first-child {text-transform:uppercase;}#yiv0720018681 #yiv0720018681activity span a {color:#5085b6;text-decoration:none;}#yiv0720018681 #yiv0720018681activity span span {color:#ff7900;}#yiv0720018681 #yiv0720018681activity span .yiv0720018681underline {text-decoration:underline;}#yiv0720018681 .yiv0720018681attach {clear:both;display:table;font-family:Arial;font-size:12px;padding:10px 0;width:400px;}#yiv0720018681 .yiv0720018681attach div a {text-decoration:none;}#yiv0720018681 .yiv0720018681attach img {border:none;padding-right:5px;}#yiv0720018681 .yiv0720018681attach label {display:block;margin-bottom:5px;}#yiv0720018681 .yiv0720018681attach label a {text-decoration:none;}#yiv0720018681 blockquote {margin:0 0 0 4px;}#yiv0720018681 .yiv0720018681bold {font-family:Arial;font-size:13px;font-weight:700;}#yiv0720018681 .yiv0720018681bold a {text-decoration:none;}#yiv0720018681 dd.yiv0720018681last p a {font-family:Verdana;font-weight:700;}#yiv0720018681 dd.yiv0720018681last p span {margin-right:10px;font-family:Verdana;font-weight:700;}#yiv0720018681 dd.yiv0720018681last p span.yiv0720018681yshortcuts {margin-right:0;}#yiv0720018681 div.yiv0720018681attach-table div div a {text-decoration:none;}#yiv0720018681 div.yiv0720018681attach-table {width:400px;}#yiv0720018681 div.yiv0720018681file-title a, #yiv0720018681 div.yiv0720018681file-title a:active, #yiv0720018681 div.yiv0720018681file-title a:hover, #yiv0720018681 div.yiv0720018681file-title a:visited {text-decoration:none;}#yiv0720018681 div.yiv0720018681photo-title a, #yiv0720018681 div.yiv0720018681photo-title a:active, #yiv0720018681 div.yiv0720018681photo-title a:hover, #yiv0720018681 div.yiv0720018681photo-title a:visited {text-decoration:none;}#yiv0720018681 div#yiv0720018681ygrp-mlmsg #yiv0720018681ygrp-msg p a span.yiv0720018681yshortcuts {font-family:Verdana;font-size:10px;font-weight:normal;}#yiv0720018681 .yiv0720018681green {color:#628c2a;}#yiv0720018681 .yiv0720018681MsoNormal {margin:0 0 0 0;}#yiv0720018681 o {font-size:0;}#yiv0720018681 #yiv0720018681photos div {float:left;width:72px;}#yiv0720018681 #yiv0720018681photos div div {border:1px solid #666666;min-height:62px;overflow:hidden;width:62px;}#yiv0720018681 #yiv0720018681photos div label {color:#666666;font-size:10px;overflow:hidden;text-align:center;white-space:nowrap;width:64px;}#yiv0720018681 #yiv0720018681reco-category {font-size:77%;}#yiv0720018681 #yiv0720018681reco-desc {font-size:77%;}#yiv0720018681 .yiv0720018681replbq {margin:4px;}#yiv0720018681 #yiv0720018681ygrp-actbar div a:first-child {margin-right:2px;padding-right:5px;}#yiv0720018681 #yiv0720018681ygrp-mlmsg {font-size:13px;font-family:Arial, helvetica, clean, sans-serif;}#yiv0720018681 #yiv0720018681ygrp-mlmsg table {font-size:inherit;font:100%;}#yiv0720018681 #yiv0720018681ygrp-mlmsg select, #yiv0720018681 input, #yiv0720018681 textarea {font:99% Arial, Helvetica, clean, sans-serif;}#yiv0720018681 #yiv0720018681ygrp-mlmsg pre, #yiv0720018681 code {font:115% monospace;}#yiv0720018681 #yiv0720018681ygrp-mlmsg * {line-height:1.22em;}#yiv0720018681 #yiv0720018681ygrp-mlmsg #yiv0720018681logo {padding-bottom:10px;}#yiv0720018681 #yiv0720018681ygrp-msg p a {font-family:Verdana;}#yiv0720018681 #yiv0720018681ygrp-msg p#yiv0720018681attach-count span {color:#1E66AE;font-weight:700;}#yiv0720018681 #yiv0720018681ygrp-reco #yiv0720018681reco-head {color:#ff7900;font-weight:700;}#yiv0720018681 #yiv0720018681ygrp-reco {margin-bottom:20px;padding:0px;}#yiv0720018681 #yiv0720018681ygrp-sponsor #yiv0720018681ov li a {font-size:130%;text-decoration:none;}#yiv0720018681 #yiv0720018681ygrp-sponsor #yiv0720018681ov li {font-size:77%;list-style-type:square;padding:6px 0;}#yiv0720018681 #yiv0720018681ygrp-sponsor #yiv0720018681ov ul {margin:0;padding:0 0 0 8px;}#yiv0720018681 #yiv0720018681ygrp-text {font-family:Georgia;}#yiv0720018681 #yiv0720018681ygrp-text p {margin:0 0 1em 0;}#yiv0720018681 #yiv0720018681ygrp-text tt {font-size:120%;}#yiv0720018681 #yiv0720018681ygrp-vital ul li:last-child {border-right:none !important;}#yiv0720018681

I agree, this is a Dynamic C Bug, this is a Digi issue, and needs to be addressed by Digi for all versions of Dynamic C that are required to develop currently shipping RabbitCore modules.

Open connections should be excluded from aging in the ARP table.

From: r...
Sent: Tuesday, March 26, 2019 7:34 AM
To: r...
Subject: Re: [rabbit-semi] ARP Table size

Instead of making the table larger I would see about getting this bug fixed. An open connection should be excluded from aging the entry in the ARP table.
On Mar 20, 2019, at 10:46 AM, s...@yahoo.com [rabbit-semi] > wrote:

Using DC 10.72A/D, with an RCM6750, when the ARP Table size is increased from 64 to 128, the executable bin file size is increased by 52k. Does that seems right? That seems way out of proportion to me.

The reason I increased the ARP table is because of the way the R3k modules work. Every device on the network that they see, they add to the ARP table, printers, computers, oscilloscopes, mobile phones, etc. Even though the module will never communicate with any of them. So what happens is, when the table is full, the next addition bumps the oldest one off the table... Eventually, the device the module is communicating with get pushed off the ARP table. The TCP connection is lost and the host has to reconnect to re-establish communication. Many a customer has complained about this, so I increased the ARP table to 20, then 64, and now to 128. I've had no complaints about this with the R6k modules, but then there are many many more R3k modules fielded than R6k. But just in case, I increased the table to 128 on the Rk6 module.

Speaking of executable size, compiling with v10.72D increases executable size by 2k over v10.72A. DC is killing me.

Steve

Instead of making the table larger I would see about getting this bug fixed.. An open connection should be excluded from aging the entry in the ARP table.

> On Mar 20, 2019, at 10:46 AM, s...@yahoo.com [rabbit-semi] wrote:
>
> Using DC 10.72A/D, with an RCM6750, when the ARP Table size is increased from 64 to 128, the executable bin file size is increased by 52k. Does that seems right? That seems way out of proportion to me.
>
> The reason I increased the ARP table is because of the way the R3k modules work. Every device on the network that they see, they add to the ARP table, printers, computers, oscilloscopes, mobile phones, etc. Even though the module will never communicate with any of them. So what happens is, when the table is full, the next addition bumps the oldest one off the table. Eventually, the device the module is communicating with get pushed off the ARP table. The TCP connection is lost and the host has to reconnect to re-establish communication. Many a customer has complained about this, so I increased the ARP table to 20, then 64, and now to 128. I've had no complaints about this with the R6k modules, but then there are many many more R3k modules fielded than R6k. But just in case, I increased the table to 128 on the Rk6 module.
>
> Speaking of executable size, compiling with v10.72D increases executable size by 2k over v10.72A. DC is killing me.
>
> Steve

Steve,

You might also want to take a look at this commit that I never merged into master:

https://github.com/digidotcom/DCRabbit_10/commit/2fc3a5268ee8d8656694367b66a78463e6f1855d

I believe it addresses the issue you’re talking about, that the Rabbit adds ARP entries from broadcast traffic for device that it’s never going to communicate with. It was a significant change that I can’t thoroughly test, so it never made it into a release.

You could test it on the RCM6750, and if it works well, back port it to Dynamic C 9 for your R3k modules.

-Tom
> On Mar 20, 2019, at 7:46 AM, s...@yahoo.com [rabbit-semi] wrote:
>
> The reason I increased the ARP table is because of the way the R3k modules work. Every device on the network that they see, they add to the ARP table, printers, computers, oscilloscopes, mobile phones, etc. Even though the module will never communicate with any of them. So what happens is, when the table is full, the next addition bumps the oldest one off the table. Eventually, the device the module is communicating with get pushed off the ARP table. The TCP connection is lost and the host has to reconnect to re-establish communication. Many a customer has complained about this, so I increased the ARP table to 20, then 64, and now to 128. I've had no complaints about this with the R6k modules, but then there are many many more R3k modules fielded than R6k. But just in case, I increased the table to 128 on the Rk6 module.

Are you using TLS/SSL? Wi-Fi? Some of that increase probably came with implementing TLS 1.2 and the WPA “KRACK” patch.

I think I also made some changes to move some constant data structures out to “far” memory, which would result in a growing executable size, but freeing up more root address space.

Take a look at the #memmap directive (and the “anymem” option) to potentially get more code compiled to unused root instead of xmem, and that could reduce executable size.

-Tom
> On Mar 20, 2019, at 7:46 AM, s...@yahoo.com [rabbit-semi] wrote:
>
> Speaking of executable size, compiling with v10.72D increases executable size by 2k over v10.72A. DC is killing me.

Steve,

The increase is likely related to the memory layout and how the processor is mapping physical addresses to root and xmem.

With separate I&D disabled, the first 52KB of address space is for combined root code and constants. The other 12KB go to stack (4KB) and XMEM (8KB?).. There might be another 4KB area that I’m forgetting about, with XMEM only getting a 4KB window.

With separate I&D enabled, I believe you have 52KB for root code and an additional 52KB for root constants mapped into the first 64KB. It’s also possible that you end up getting more space for root variables, I can’t entirely recall that mapping.

So the increase in file size probably means you have a lot of unused 4KB pages in those two root memory areas of 52KB. As you add more root constants and code, they will grow to fill the unused pages and your file size shouldn’t change.

You could take a look at the .map file to get an idea of how it’s mapping root addresses to physical addresses. I think there are also some samples that print out reports of memory mapping/usage that could help explain the change as well.

-Tom
> On Mar 20, 2019, at 8:07 AM, s...@yahoo.com [rabbit-semi] wrote:
>
> Correction. The 52k increase in executable size was due to enabling separate instruction and data spaces. When I increased the ARP table to 128, I got an "Out of variable data space" error. Enabling separate instruction and data spaces removes the error.
>
> So now the question is, why should enabling separate instruction and data spaces increase the executable by 52k? Leaving the ARP at 64, there should be no increase in size, just a rearrangement of the code and data.

Probably a bit dangerous, but I seem to recall a way to make arp entries permanent in some way?

On 3/20/2019 7:46 AM, s...@yahoo.com [rabbit-semi] wrote:
Using DC 10.72A/D, with an RCM6750, when the ARP Table size is increased from 64 to 128, the executable bin file size is increased by 52k. Does that seems right? That seems way out of proportion to me.
The reason I increased the ARP table is because of the way the R3k modules work. Every device on the network that they see, they add to the ARP table, printers, computers, oscilloscopes, mobile phones, etc. Even though the module will never communicate with any of them. So what happens is, when the table is full, the next addition bumps the oldest one off the table. Eventually, the device the module is communicating with get pushed off the ARP table. The TCP connection is lost and the host has to reconnect to re-establish communication. Many a customer has complained about this, so I increased the ARP table to 20, then 64, and now to 128. I've had no complaints about this with the R6k modules, but then there are many many more R3k modules fielded than R6k. But just in case, I increased the table to 128 on the Rk6 module.
Speaking of executable size, compiling with v10.72D increases executable size by 2k over v10.72A. DC is killing me.
Steve

Correction. The 52k increase in executable size was due to enabling separate instruction and data spaces. When I increased the ARP table to 128, I got an "Out of variable data space" error. Enabling separate instruction and data spaces removes the error.

So now the question is, why should enabling separate instruction and data spaces increase the executable by 52k? Leaving the ARP at 64, there should be no increase in size, just a rearrangement of the code and data.

Steve

Using DC 10.72A/D, with an RCM6750, when the ARP Table size is increased from 64 to 128, the executable bin file size is increased by 52k. Does that seems right? That seems way out of proportion to me.

The reason I increased the ARP table is because of the way the R3k modules work. Every device on the network that they see, they add to the ARP table, printers, computers, oscilloscopes, mobile phones, etc. Even though the module will never communicate with any of them. So what happens is, when the table is full, the next addition bumps the oldest one off the table. Eventually, the device the module is communicating with get pushed off the ARP table. The TCP connection is lost and the host has to reconnect to re-establish communication. Many a customer has complained about this, so I increased the ARP table to 20, then 64, and now to 128. I've had no complaints about this with the R6k modules, but then there are many many more R3k modules fielded than R6k. But just in case, I increased the table to 128 on the Rk6 module.

Speaking of executable size, compiling with v10.72D increases executable size by 2k over v10.72A. DC is killing me.

Steve