NetBurner Community Forum

We are trying VERY HARD to help you. If you ignore our questions you make helping you IMPOSSIBLE.
Please [provide SPECIFIC answers to each of the numbered questions below.

1)The speed issue is when you load an htm page from a netburner server to a browser. (Chrome)
Yes /No? (The only reason I ask this is you aid it was slow from your development environment to eclipse)

2)Does the HTM page have any functioncall or variable dynamic content,
I don't care about dynamic jquery or anything else, specifically does it have the C++ callback function call tags in it?

2a)If the answer is yes if you make this dynamic content static does it load faster?
2b)If the answer is yes can you provide the code that is being called with this?

2c)If it does not have dynamic content and the dynamic content is generated by jquery... please exaplin how the dynamic content is generated?
IE is jquery trying to load a json file or something?

3)What does Wireshark show... ie capture a wireshark trace of the slow and let us see that.

Sorry, I though I was providing explicit responses.
As I said previously, i added the web files to an early post.

1. Yes, the problem is the Netburner providing web pages to a browser like chrome.

2. Each webpage calls a number of additional files from the Netburner. These are data files to provide the data to be displayed on the web page and also some javascript files are called. All the web page does is ask for a file. Here is the typical call for a data file:

$.ajax({url: pageData, async: false, dataType: 'json', success: function(data){
$.each(data, function(){ locationProperties.push(this); });
}}); // ajax

For example the INDEX.HTM
This uses:
<link href="site.css" rel="stylesheet">
<script src="https://ajax.googleapis.com/ajax/libs/j ... "></script>

And then calls:
$.ajax({url: 'config.jsn', async: false, dataType: 'json', success: function(data){
$.each(data, function(){ stationProperties.push(this); });
}}); // ajax
and then calls the following about 4 times:
$.ajax({url: pageData, async: false, dataType: 'json', success: function(data){
$.each(data, function(){ locationProperties.push(this); });
}}); // ajax
where pageDate points to 300 byte long json configuration files.

Doing a test just now the page loaded reasonably quick. The index.htm file took 44ms, the site.css (19k long style sheet) took 35 seconds, and each of the json files took about 10mS

Another example is the LOCALE.HTM. This displays highcharts.
It uses:
<link href="site.css" rel="stylesheet">
<script type="text/javascript" src="js/jq_182.js"></script>
<script src="js/highchrt.js"></script>
<script src="js/export.js"></script>

and the loads about 8-10 data files into highcharts using calls similar to:
pageData = site + "/data007.jsn";
$.getJSON(pageData, function(data){
var series = {
name: pressure_labels[3],
color: 'black',
data: []
};
$.each(data, function(i,item){
series.data.push(item);
});
chart2.addSeries(series);

Trying this out just now, the locale.htm file took 39s to load, site.css took 24ms, each of the javascript files took about 150ms each, and each of the json data files took about 10ms each.

I am currently using chrome to do all the performance testing, but will endeavor to load wireshark and do the same tests and post the results.
thanks for your support

I have attached a capture of the loading of index.htm using wireshark.
The netburner is on 192.168.1.120 and the PC is on 192.168.1.54

What other tasks are running on the NetBurner?

Do you have any user tasks with a priority higher (,lower number) than the the http server?

I must have not submitted one of my responses as I thought i had already sent a description of the processes running. They are:

HTTP - priority 45
FTP - priority 48
Main - priority 50 - infinite loop with loop delay OSTimeDly(5) that checks alarm flags (from alarm Task) and executes time sensitive activities. Minimum alarm interval is 1 second
Communications - priority 52 - Idle waiting for a semaphore from 'Main' every 15 minutes to initiate communications to remote devices.
Alarms - priority 58 - Infinite loop with OSTimeDly(TICKS_PER_SECOND) (i.e. every second) and sets flags when one of the alarms activates.
LCD Menu - priority 61 - Infinite loop waiting for touchscreen press with loop delay OSTimeDly(5) - touchscreen rarely used but loop calls DSPIStart twice each loop
External IP request - priority 62 - Idle - waiting for semaphore from LCD Menu
The default tick rate is 20 per second.

The 'alarms' task only has 5 lines of code in a for loop with about 5 iterations and executes only once a second, so it is unlikely to cause any problems.
The 'communications' task is only called once every 15 minutes and is idle otherwise waiting for a semaphore.
The 'External IP request' task is idle for all my testing waiting for a semaphore.
The 'main' task only has about 20 lines of code and does not execute any activities. It simply posts semaphores or sets flags or toggles the 'heartbeat' LED. I can change the loop delay on this to 10 (i.e. half a second) as it only acts on alarms that are raised at a maximum of 1 second intervals.
The 'LCD Menu' is not used so the only activity it performs checks the touchscreen 4 times a second by twice calling DSPIStart. I cant really change the loop time on this because it is already at the edge of comfortable responsiveness.

However, other than other 'system' processes (ESND, IP, TCPD) then HTTP is the highest priority and no other process should lock up the processor for any significant duration without calling a the OS and allow for pre-empting.

how big is the Local.htm file?

Does it have ANY functioncall or netburner filled in variables in it?

Paul

The local.htm file is 24k.
I outlined the functionality in an eraly post.

It loads highcharts.js and export.js used in high charts.

It then calls a number (between 1 and 8) of json files around 2-8k in length using $.getJSON

According to chrome development tools, the time taken to load these files in in the order of 20ms.

Change line 1140 of ethernet.cpp from: to: Yes, this is a small, simple, stupid change. Yes, this will fix the issue.

The problem that occurs is that *for some reason* the MCF5441X's hardware queue for transmit packets will sometimes disable the transmit request, even though additional packets are ready to be sent and marked as such. The fix is to never allow multiple packets to queue.

This is precisely the issue you are encountering. The smoking gun is that the FIN/ACK that closes the hung TCP socket is sent immediately after an ARP request for the Netburner module's IP. This triggers an additional ethernet TX, waking up the transmitter.

-Dan

That works great. The web pages were taking between 20-30 seconds to open and now they take about 20ms.

i still have a problem with one web page that takes a long time to open, but i think I have more work to do on it to improve its performance so i will try that in the next week or two.

Thanks

I've had a lot of issues over the years of sluggish web page behavior. I've noticed since switching to 2.7.7 that has this change, the responsiveness has been MUCH better!