An unusual network problem when using Eyewire

Eyewire Bugs
#1

I’m getting a problem with ultra slow DNS resolution that seems only to occur when I have been using Eyewire for a while. Image loading becomes slow in the app, then it will freeze and refuse to reload the application. The unusual feature is that this also affects another browser on the same machine. The phenomenon lasts for a few moments then clears.


I’ve downloaded approximately 1Gb of data in the past day with other browsing and not seen this except when using Eyewire. I’m trying to catch it using a laptop to see if it is the machine, or at the router (or further back).

Has anyone else seen this sort of behaviour?

Edit - I’m using Chrome (latest) and have turned off network prediction to see if that helps.

Edit 2 - Another computer connecting to the router via Wifi displays the same behaviour.
#2

Well, I have a partial answer that raises another question…


The phenomenon is stalling the router. I suspected that it was stalling to clear logs, and while watching the intrusion detection logs, I noted that when eyewire appears to stall, there is a tcp port scan that appears in the logs.
#3

Sounds like you know what you are doing… Is your router configured in a non-default manner?  Running a custom firmware?

#4

The router is a standard BT Homehub 1.5. They have a known firmware issue that call logs, or intrusion detection logs can overload the router for a while and cause what looks like a DNS failure. It is unlikely to be British Telecom’s DNS server, so the router is probably at fault. I just noticed that when the problem of stalling occured, a port scan was blocked by the intrusion detection.


The odd thing is that I am only seeing this behaviour since using Eyewire. I will be getting a new router sometime; my current theory is that the app is doing something (unwittingly) that is causing the router to throw a fit and misinterpret the dataflow as either intrusion or garbage, and cause a need for it to stall to sort itself out.

shrug


#5

Well we are making a lot of requests quickly for a lot of data.  Mabye at some point the traffic starts to look like spam, DDoS or some such.  I guess we’ll wait and see if anyone else has this problem.

#6

I’ve been experience what seems to be this same problem, but only for the last few days. Now, I can’t get any load to complete. It may be of note that the last two problems may have massive data, with the working window half or more filled with blue. (the problem volume may be at the cell body or something) 


At present, I cannot contribute to the project at all.
#7

I’m wondering if this is the cell body problem raised in a few different threads. It seems that there have been a number of tasks with cell bodies in the last couple of days. These take a large amount of time to load - up to 30+ minutes if at all.

http://forum.eyewire.org/discussion/comment/19#Comment_19

Are we suppose to abort these tasks, if we can abort them?

#8

@simulacron3 @readingite


The cell body problem is a computational one that lies in the way the browser is processing the tasks. The one I refer to above is related to the intrusion detection filters on an old router.

For anyone else reading this, the problem was resolved completely by replacing the router with a newer netgear one. The faster chipset cpu, and a smarter firewall has not repeated the problem. 

Its specific symptoms are that the response of the browser will become slower after doing multiple tasks, and eventually refuse to load pages from any site, but will have no significant CPU load. And… the problem will manifest on other computers on the network behind the router.


#9

So you didn’t see this problem on any other sites?

#10

@balkamm


No - the problem was specific to a flood of transactions with an address in the MIT range. The router was randomly misinterpreting it as a TCP attack. It was specific to interacting with eyewire. It was one of those cheapo routers that British Telecom gives away. Problem was resolved by replacing the router implying that the router was at fault.

:slight_smile:
#11

Okay, well thanks for sussing this out.  I hope no one else has this problem.  I don’t think we are doing anything nefarious…