PDA

View Full Version : error msg



JackndBox
02-27-2005, 03:01 PM
whats SendIdaMessage : V3netsend failed. EC=-7,bytes_sent=0 mean?
if it means what i think,then you guy's need to beef up your server.
I notice i get this when we go thru those killer 3 to 4 minute spans of not receiving work.
i hate wasting electricity

Electrolyte
02-28-2005, 03:36 AM
I think it means it had a problem uploading the WU to the server, and I also think it tries again.

alok vaid
02-28-2005, 04:45 AM
Are you still receiving error messages?

KWSN_Dagger
02-28-2005, 08:27 AM
I'm also receiving this error msg.

[FIDA] Reporting Results
[FIDA] Connecting to Server
SendIdaMessage: v3NetSend failed. EC=-7, bytes_sent=0

Along with 5 secs to 2 mins of waiting. :stomp:

omer
02-28-2005, 10:02 PM
we are working on it :)

try the new client, it saves your work units!

KWSN_Dagger
03-24-2005, 12:20 AM
My client keeps causing an error with this dll file. I know that this dll is what makes eon run, but for whatever reason the client keeps backstabbing it. It occurs just after a new unit starts. Win ME ( i know it sucks) running text version.

omer
03-26-2005, 04:01 PM
paste the output that shows on the screen, i also replied to your email...

KWSN_Dagger
03-26-2005, 05:35 PM
Actually there is no output client side. An error box pops up saying that Client.exe has caused an error in al110c.dll and will be shut down. Letting it sit there doesn't do anything. Could be a bad work unit maybe if that is possible. If i'm the only one with this problem, then maybe it's my computer, and not with the client.

omer
03-26-2005, 07:40 PM
pepe (Carlos) is the only one who used WinME that i know... so lets wait for him to see this post and reply .. i will also send him a pm

em99010pepe
03-27-2005, 10:03 AM
Sorry guys but I was out for three days. I installed again the client on a WinMe machine and no problems so far.
I tested the GUI and the command line version.

Carlos

PS( I have to pick up my parents at airport, be back soon to test once more the client)

EDIT: Fargot to test it again. Tomorrow I will see.

AMDave
04-11-2005, 10:58 AM
I too am getting a lot of these failed upload error messages in the output text stream.
I am using the Linux client. It is frustrating because I see my output rate fall when others are still ok. Is there a server I/O issue ? Is there something I can change on my end to reduce this problem ?


[FIDA] Connecting to Server
SendIdaMessage: v3NetSend failed. EC=-7, bytes_sent=31192
[FIDA] Failed - SendIdaMessage
[FIDA] Failed - Report results
[FIDA] ZZZ - Sleep for 5 seconds
[FIDA] Reporting Results

You noted that the client has been modified to save it's WU's pending upload (that is the way I interpret the note above). Can you provide a little more info on that. I don't think I have witnessed this in the Linux client.

Also, on the downloads page there is a broken link "The script eon.sh is a shell script" where "eon.sh" was supposed to link to a shell script file, but it is not available.

Also how can I change my email address ?

Thx. AMDave.

Mustard
04-11-2005, 01:28 PM
I'm also having way way too many error messages today, plus a lot of waiting for work units. more time waiting than processing. :( Linux clients too.

JackndBox
04-11-2005, 02:21 PM
its doin it on windows clients too

rjkc4
04-11-2005, 02:29 PM
All my clients are active now!

:thumbs: :thumbs:

Kevin

graeme
04-13-2005, 11:17 AM
It would be helpful to know if these error messages are still showing up. We were messing around with the windows library at 1-2am last night, and accedentally caused communications errors on all clients. Is anyone seeing errors persisting today? Also, are any windows users finding that they can't load the new clients? Are the WinME machines working, for example? From the server end, things are looking good right now, and I expect to see a much higher output from the windows clients today. BTW, I can't say enough about how useful the detailed Free-DC stats have been for monitoring the project -- thanks guys.

black_civic55
04-13-2005, 11:26 AM
the error message im getting right now is...

udating client application please wait.....
unable to open aloptc.dll

then it sleeps for a certain amount of seconds.

this is the windows version.

rcoulter
04-13-2005, 11:27 AM
Graeme,

Time is 11:30 EST and I'am still getting communications errors on both the Linux and the new Windows clients, but not on every return, about every second or third.

Randy

birdman2584
04-13-2005, 11:29 AM
im getting a lot of communication errors with the server as well....it waits for 5, up to 60 seconds. Im running the windows version.

Mustard
04-13-2005, 12:43 PM
Graeme,

Actually, today is worse than it's been in quite a while for me. I notice that there are a couple more high producing individuals according to Bok's stats. Time is now 09:40 PST and the bulk of my systems are cruising along on 60 sec waits now. Seems as the more heavy hitters that put resources on the project, the more delays start being encountered. I'd add to that it isn't an internet issue as traceroutes are not showing any delays. It really appears that something in the server process is loading up somewhere/somehow. It is affecting both windows and linux for me. Crunching on eon under a different account name than Lexx.

Bruce

graeme
04-13-2005, 12:56 PM
I think the problem has to do with a few machines which are not properly updating. They are pinging the server for a new library over and over. This is, of course, our fault, but if you can help pin down the problem, it will reduce the load on the server. The two windows machines are from the black_civic, and Odessa888; can you give details on these machines? Are they WinME boxes, or do they have anything non-standard? There is also an older linux client which is pinging constantly for updates. We've made the newer client binaries less aggressive, but this is one of the older agressive ones. I think that the constant demand from these few machines to download the library is causing the general communication issues. Well, we'll post back with any changes in the status.

black_civic55
04-13-2005, 01:02 PM
the computer i have running the client right now is just basic windows XP. Since my earlier post the client was able to update and is doing work units. Now though i am having the normal connectivity problems when uploading results to the server. Every so often though it will work.

Noticed one thing when looking at the stats however. My client says its done 24 WUs. However, the stats page says ive done 40 today....

graeme
04-13-2005, 01:16 PM
Do you have another windows machine? I'm still seeing one requesting an update.

black_civic55
04-13-2005, 01:38 PM
i have two others. one i know is not running. the other may be but i highly doubt it. so there really should be only one client running and it does its jobs every so often but gets problem trying to get work every so often too.

I'll find out within the next 2 hours though if the 3rd machine is running it.

graeme
04-13-2005, 02:28 PM
I've temporarily blocked the old linux client. I expect the communication should clear up now.

TeeJay
04-13-2005, 02:42 PM
Originally posted by graeme
I've temporarily blocked the old linux client. I expect the communication should clear up now.

Not for me !

[FIDA] Cryptography Enabled
[FIDA] Initializing
[FIDA] Loading Config File
Loading from: aloptc.dll
Dimer Initialize
[FIDA] Email Address: xxxxxx@xxxxxx
[FIDA] Requesting Assignment
[FIDA] Connecting to Server
[FIDA] Processing Assignment

Dimer DoAssignment
Dimer: Start
Image Done: U: 0.0576127 FC: 501 TS: 56
Dimer: Done
HSize: 78
Good Pref: 7.23045e+012
Minima, saddle : -0.000144886 <- 0.0576127 -> -0.0593511
[FIDA] Reporting Results
[FIDA] Connecting to Server
Dimer UndoAssignment
[FIDA] Work Unit Completed
[FIDA] Requesting Assignment
[FIDA] Connecting to Server
[FIDA] ZZZ - Sleep for 5 seconds
[FIDA] Requesting Assignment
[FIDA] Connecting to Server
[FIDA] ZZZ - Sleep for 10 seconds
[FIDA] Requesting Assignment
[FIDA] Connecting to Server
[FIDA] ZZZ - Sleep for 20 seconds
[FIDA] Requesting Assignment
[FIDA] Connecting to Server
[FIDA] ZZZ - Sleep for 30 seconds
[FIDA] Requesting Assignment
[FIDA] Connecting to Server
[FIDA] ZZZ - Sleep for 40 seconds
[FIDA] Requesting Assignment
[FIDA] Connecting to Server
[FIDA] ZZZ - Sleep for 60 seconds

graeme
04-13-2005, 02:46 PM
were those messages from right now?

TeeJay
04-13-2005, 02:59 PM
Originally posted by graeme
were those messages from right now?

Those were from like 10 min ago.

Am still getting sleep 5 sec, and as much as 40 sec in the last
10 minutes. Probably (6) 5 sec sleeps and (2) 40 sec sleeps.

Hope that helps.

graeme
04-13-2005, 03:09 PM
Thanks, yes, I've been watching over many minutes now, and I do see the error messages as well. Well, the pressure's on us to fix this now. I'll post as soon as we figure something out.

Mustard
04-13-2005, 03:14 PM
Okay.... meanwhile I'll switch to something else. :)

graeme
04-13-2005, 05:59 PM
I've increased the size of the work units to reduce the communication on the server. I think this has brought things back under control.

AMDave
04-14-2005, 09:27 AM
graeme,

Thanks for looking into the I/O issue.
since the change in wu size things appeared to be going well, but right now I'm getting a lot of sleeps. 2 hours ago, 1 client went through 40 x 60 second sleeps before a connection was achieved with the server, then it moved on again.
but right now I am getting up to the 60 second sleeps regularly across all clients.
I hope the feedback is useful.

AMDave


sorry. forgot to add ...
running 1 instance of the latest Linux client on 4 machines
[2nd edit]
all using the "libaloptc.so" library
[/2nd edit]

IronBits
04-14-2005, 07:13 PM
I'd really like to help out, but I can't when I see this, after a fresh install on XP :cry:

[FIDA] Cryptography Enabled
[FIDA] Initializing
[FIDA] Loading Config File
Loading from: al110c.dll
[FIDA] Failed - Cannot Load Library: dllerror: errro code =

and ...

[FIDA] Reporting Results
[FIDA] Connecting to Server
[FIDA] Failed - RecvIdaMessage
[FIDA] Failed - Report results
[FIDA] ZZZ - Sleep for 5 seconds
[FIDA] Reporting Results
[FIDA] Connecting to Server
[FIDA] Failed - RecvIdaMessage
[FIDA] Failed - Report results
[FIDA] ZZZ - Sleep for 10 seconds
[FIDA] Reporting Results
[FIDA] Connecting to Server
[FIDA] Failed - RecvIdaMessage
[FIDA] Failed - Report results
[FIDA] ZZZ - Sleep for 20 seconds
[FIDA] Reporting Results
[FIDA] Connecting to Server
[FIDA] Failed - RecvIdaMessage
[FIDA] Failed - Report results
[FIDA] ZZZ - Sleep for 30 seconds

graeme
04-14-2005, 07:23 PM
Can you give some other details, between these two snippets. At the start the al110c.dll was not able to load. That's good. It should have then downloaded a new library called aloptc.dll. Did it do this and successfully load the library. If it did, there would be a 'Dimer Start' message. I think it must have because the final error is about trying to report results, so it must have calculated something to report.

Then, are these final communication errors continuous, or does it finally connect and go on with other work units?

Thanks for your help, these details will help get to the bottom of this.

IronBits
04-14-2005, 08:09 PM
The ... meant everything else appears to be normal output.
The problem is not being able to report to the Server, especially being that this client is so heavily dependant on a connection to the Server and slows down your results being returned, and the amount of work we can do for you. :bang:

Keep at it, you'll win eventually :D

graeme
04-15-2005, 01:00 AM
Can anyone post an update on communication problems? Are these ongoing, or have they settled down now? AMDave, I see a lot of work units pouring in, so are the communication problems intermittent?

One thing I have mentioned before is that the server periodically needs to do a little calculation on it own, and the clients are left to wait. This should take no more than a minute, and happen no more than a few times per day. Communication error messages which occur more frequently do indicate a problem.

I forgot to address earlier questions. On windows you can use Omer’s little settings utility to change your user name. Also, on any system you can edit the client.cfg file and change the name after the email= tag. Remember on windows to leave the end of line character, which may show up as a box symbol. There is also a little perl script called setuser.pl which will make the change for you on linux or os x.

Sorry about the missing eon.sh script for automatically starting clients. I didn’t realize that anyone besides me was using it, but that’s no excuse for not having it properly linked.

Thanks for your comments and calculations.

AMDave
04-15-2005, 05:47 AM
Yes it is intermittent across the clients. Sometimes they are all going fine. Other times one or more are spinning their cogs for a while.

About the server-side calculation: Does the need for the server-side calculation increase in frequency if the rate of WU return increases ? and does it take longer to compute when there is an increase in the number of WUs returned ?

Someone mentioned earlier that the client pings the server. If it does this too frequently, could it be causing the campus Intrusion Detection System to temporarily block our IP's ? Do they have a log file that might prove / disprove this ?

I know I can put a different email address into the client config. But what is not clear is what I have to do to ensure that my points continue to come up under the existing Nickname. The login page provides for change of password but not for email addy. There is no info on this in the FAQ so I thought I'd better ask. I am reticent to change the email address in my clients until I am sure what the outcome will be.

About the missing eon.sh script: no worries, I rolled my own anyway :)

Thanks for your reply.

TeeJay
04-15-2005, 09:59 AM
Originally posted by graeme
Can anyone post an update on communication problems? Are these ongoing, or have they settled down now? AMDave, I see a lot of work units pouring in, so are the communication problems intermittent?

Thanks for your comments and calculations.

Just ran 2 clients on a 2.8 Xeon for one hour.
NO communication problems at all.

Now to see just how much work got done in that hour...

Thanks for your support !

>>TeeJay

rcoulter
04-15-2005, 11:57 AM
I haven't had any communications errors in at least the last hour either Linux or Windows

Randy

Mustard
04-15-2005, 12:01 PM
Nor have I had any errors either.

black_civic55
04-15-2005, 12:04 PM
same here

em99010pepe
04-15-2005, 12:17 PM
Everything seems to be running smoothly.

Carlos

black_civic55
04-15-2005, 12:56 PM
question though, are you still sending out larger WU's because if the update was supposed to make the client 3x faster then ummm i dont think it worked!!

graeme
04-15-2005, 01:38 PM
The work units are still larger. I think this is nessecary to keep the current system stable. I'm not sure how much slower the larger WUs are, and therefore how the speed of a current windows machine will compare. We did test the old windows client against the new one on the same WUs and found the 3x increase in speed. This ratio should still be reflected in the relative increase in speed of the windows client to complete a work unit as compared to a linux client. The two should have a similar performance now.

IronBits
04-16-2005, 11:05 AM
This is what keeps me from running this project.
It takes my computer like 15 seconds to complete the task, then this
[FIDA] Created: Thursday November 4, 2004 03:18:17 UTC
[FIDA] Signed: Wednesday April 13, 2005 05:18:42 UTC
Loading from: aloptc.dll
Dimer Initialize
[FIDA] Requesting Assignment
[FIDA] Connecting to Server
[FIDA] Processing Assignment

Dimer DoAssignment
Dimer: Start
Image Done: U: 0.211208 FC: 553 TS: 80
Dimer: Done
HSize: 105
Good Pref: 4.51583e+013
Minima, saddle : -0.0033301 <- 0.211208 -> -0.000149288
[FIDA] Reporting Results
[FIDA] Connecting to Server
[FIDA] Failed - RecvIdaMessage
[FIDA] Failed - Report results
[FIDA] ZZZ - Sleep for 5 seconds
[FIDA] Reporting Results
[FIDA] Connecting to Server
[FIDA] Failed - RecvIdaMessage
[FIDA] Failed - Report results
[FIDA] ZZZ - Sleep for 10 seconds
[FIDA] Reporting Results
[FIDA] Connecting to Server
[FIDA] Failed - RecvIdaMessage
[FIDA] Failed - Report results
[FIDA] ZZZ - Sleep for 20 seconds
[FIDA] Reporting Results
[FIDA] Connecting to Server
[FIDA] Failed - RecvIdaMessage
[FIDA] Failed - Report results
[FIDA] ZZZ - Sleep for 30 seconds
[FIDA] Reporting Results
[FIDA] Connecting to Server
[FIDA] Failed - RecvIdaMessage
[FIDA] Failed - Report results
[FIDA] ZZZ - Sleep for 40 seconds
[FIDA] Reporting Results
[FIDA] Connecting to Server
[FIDA] Failed - RecvIdaMessage
[FIDA] Failed - Report results
[FIDA] ZZZ - Sleep for 60 seconds

I spend more time trying to upload a result than I do getting the work done.
I'll keep checking back...

black_civic55
04-16-2005, 11:07 AM
i've been getting that today too

AMDave
04-21-2005, 07:45 AM
graeme,

after your hard work I am reticent to post this...
rather than post a copy of the output, I'll just state that my clients are now up to over 20 x 60 second sleeps again (stopped and restarted, but the problem is persisting)
I noted that initially, some contributors were slow to resume uptake of the WUs and things were going well after the restart.
However, I now see the project contribution rate approaching higher levels again and see others higher in the throughput stakes and, for me at least, the sleep problem has returned.
so I am now wondering about a couple of things:
1 - If some contributors have faster completion times, could their frequency of server requests be hogging the server availability ?
2 - does the server have an upper limit of WU availability ?
and
3 - is there any possibility that the client could be falsely reporting sleeps whilst still processing WUs ?
(question 3 is the result of a sceptical mind. I intend no offense to the code cutter but always find value in thinking outside the box [intentional pun :) ] )

Thanks for your time.

graeme
04-21-2005, 10:52 AM
AMDave, thanks for the note. One think that would help is to know if the errors are in blocks, and correspond to specific times at which the server is doing it's own calculation. In the past day, these were at (central daylight time):

-rw-r--r-- 1 graeme henkelman 6295214 Apr 19 22:04 r0000.xyz
-rw-r--r-- 1 graeme henkelman 6298075 Apr 20 00:46 r0059.xyz
-rw-r--r-- 1 graeme henkelman 6300246 Apr 20 03:08 r0083.xyz
-rw-r--r-- 1 graeme henkelman 6302566 Apr 20 07:33 r0111.xyz
-rw-r--r-- 1 graeme henkelman 6304965 Apr 20 08:37 r0114.xyz
-rw-r--r-- 1 graeme henkelman 6309388 Apr 20 12:01 r0149.xyz
-rw-r--r-- 1 graeme henkelman 6311570 Apr 20 12:22 r0150.xyz
-rw-r--r-- 1 graeme henkelman 6312974 Apr 20 13:36 r0160.xyz
-rw-r--r-- 1 graeme henkelman 6315752 Apr 20 16:30 r0219.xyz
-rw-r--r-- 1 graeme henkelman 6318510 Apr 20 21:36 r0431.xyz
-rw-r--r-- 1 graeme henkelman 6321733 Apr 21 05:11 r0686.xyz
-rw-r--r-- 1 graeme henkelman 6322613 Apr 21 05:47 r0687.xyz
-rw-r--r-- 1 graeme henkelman 6326272 Apr 21 07:45 r0690.xyz

For the current calculation, this is typical, with about 10 such delays per day, lasting about 2-3 minutes each. If the timeouts you are seeing correspond to these times, the errors are expected.

If, on the other hand, the errors are scattered throughout the day, and perhaps at different times on different clients, there must be another explanation, and this really would be something to figure out.

Can you tell me which scenario is closer to what you are seeing?

With respect to your other questions, it is possible for the server to become overloaded with requests for WUs, especially if clients are reporting results quickly. I don't see evidence of this at the server end (except for the localized periods I mentioned). But, there is no preference given to any client over another. It is a normal TCP/IP stack, and requests are processed in the order they arrive. There is no upper limit on WU availability, and I certainly expect that if the client claims to be sleeping, it is because it's not working. The last thing we need is lazy clients, sleeping on the job.

AMDave
04-21-2005, 06:00 PM
Thanks for the reply graeme.

my sleeps seem to go for over 20 minutes at a time.
the last one started at around 21:10 UTC and went for over 25 minutes.
it appears to have commenced about 20 minutes before one of your rxxxx blocks.

perhaps I am in a poor spot on the net...how long does the client wait for a response from the server before initiating a sleep ?
one ping took 4071 ms ! several were over 3000 ms.

graeme
04-21-2005, 06:19 PM
Ok, so it sounds like this problem is not related to the sever work. Twenty minutes is way too long, and if the times don't match, it's out of the question. I wonder if there is a general communication problem. Do you ever see any other network problems using a web browser, for example? The machine here is connected via a gigabit line to the university, and to the backbone which connects the major US universities. Your ping time of several seconds is just crazy.

I'm not sure how the TCP/IP timeout works. It's implemented at a lower level. In our code, we try to establish a socket. If we get an error from the OS, saying that a TCP message timed out, we consider the connection failed. At that point, the client waits for 5 seconds before trying again. The wait time should increase until it gets to a minute, and stay there, so that a machine which never connects will keep trying every minute.

One test would be to ping a machine on the same network as eon to see if the ping times are just as long. One such machine is theory.cm.utexas.edu. Perhaps I could also get Omer to make a client binary which writes some timing data, to help debug this.

AMDave
04-22-2005, 03:49 AM
graeme,
I just got back from work and saw your post.

No I don't normally have that experience.
I ran a traceroute test this morning on the eon server and found this amongst the hops:
ser2-v60.gw.utexas.edu (*ip*) 2815.257 ms

I just ran the ping test on "theory" and was able to get a consitent 0.23 response rate from it and other points in the campus network.
146.6.143.207 "eon" is not responding at all at present - 100% packet loss.

I did notice this morning when the ping test was worked (but was slow), the traceroute test never completed the final hop from wel-v755.gw.utexas.edu to "eon"

In this afternoon's test on "theory" traceroute was able to terminate it's search at "theory".
and "ser2-60" exhibits no delays at all.

There has to be something different about the connection between "theory" and the campus to the connection between "eon" and the campus.
I wonder what it is.
Do you have another NIC ?

AMDave
04-22-2005, 06:39 AM
graeme,
I just got back from work and saw your post.

No I don't normally have that experience.
I ran a traceroute test this morning on the eon server and found this amongst the hops:
ser2-v60.gw.utexas.edu (*ip*) 2815.257 ms

I just ran the ping test on "theory" and was able to get a consitent 0.23 response rate from it and other points in the campus network.
146.6.143.207 "eon" is not responding at all at present - 100% packet loss.

I did notice this morning when the ping test to "eon" worked (but was slow), the traceroute test never completed the final hop from wel-v755.gw.utexas.edu to "eon"

In this afternoon's test on "theory", traceroute was able to make the same hop and terminate it's search at "theory" no problems. Also "ser2-60" now exhibits no delays at all.

There has to be something different about the connection between "theory" and wel-v755.gw.utexas.edu to the connection between "eon" and wel-v755.gw.utexas.edu.
I wonder what it is.

Do you have another NIC you can try?

graeme
04-22-2005, 10:10 AM
AMDave, the timing of your test unfortunately coincided with a power outage across campus. Theory was able to restart on it's own, but eon tends to force a fsck at reboot. It will be back within the hour.

AMDave
04-22-2005, 06:21 PM
I know that the server was down.
the parts in my post relate to the tests prior to the server failing.
there seems to be a breakdown between eon and the last hop.
same test between theory & the last hop shows a good result, but eon does not.
I just tried again with the same result.
the last hop is ok from wel-v755.gw.utexas.edu to theory, but not to eon.

graeme
04-22-2005, 10:25 PM
AMDave, I finally see the same thing you are describing. When I try a traceroute from my home machine, I get:

...
11 iah-edge-08.inet.qwest.net (205.171.31.26) 33.115 ms 33.83 ms 33.668 ms
12 65.112.240.186 (65.112.240.186) 38.023 ms 37.774 ms 37.143 ms
13 ser2-v60.gw.utexas.edu (192.12.10.2) 35.616 ms 36.856 ms 36.114 ms
14 ser9-v703.gw.utexas.edu (128.83.9.1) 37.808 ms 36.33 ms 36.897 ms
15 wel-v755.gw.utexas.edu (128.83.9.114) 53.623 ms 36.114 ms 37.679 ms
16 * * *
17 * * *
18 * * *
19 * * *
20 * * *
21 * * *
22 * * *
...

Thanks again for mentioning this. I still don't know what this is about, but it's a place to start. I can ping the machine in 40ms, and ssh without delay. Could traceroute be blocked? I'll ask around about this next week, and let you know if I find anything out.

graeme
04-22-2005, 10:46 PM
Actually, after a few tests, I realized that traceroute works on a port which is blocked by the firewall on eon. The traceroute failure does not have anything to do with general communication errors.

AMDave
04-23-2005, 04:39 AM
Great.
We have eliminated something else then.

When I ping eOn (I am not doing this often), sometimes I get around 500ms, but often it goes up over 2000, 3000 and 4000 and then drops back down. I have noticed that this tends to occur on one of the Qwest servers or on ser2-v60.gw.utexas.edu.

Something else I noted in testing was that when I restert the client because it has had 30 or 40 sleeps, the client does not ever wait longer than 1 second before going back into sleep mode. Personally, I think this is too short. Can Omar easily change the connection-timeout period in the client? or is it a major hassle?

em99010pepe
04-23-2005, 06:04 AM
A few questions:

1º - What's the size of the jobs in terms of hard disk space?

2º - I noticed this a few months ago, when you refresh an internet page when eOn sends a job, the latter just waits until the connection is free. This still happens! So the information is sent in series instead of in parallel. Am I right?

I'm also just trying to help.

Cheers,

Carlos

graeme
04-23-2005, 11:23 AM
I'll talk with Omer about trying to change the timeout. There is a way to change this on the server for general TCP/IP communiciation, but I think it is the client which is timing out. There must be some algorithm which allows machines with lower bandwidth to wait longer. If a machine with dialup had a 1s timeout, it wouldn't connect to anything.

The work units don't really take any disk space. The client will only write to disk if it downloads a new library, and if it's output is being piped to a file.

The connection between delays with the server and with the web server is interesting. They do share the same TCP/IP stack, but I'm surprised they are related in the way you (Carlos) describe. When the server is busy, I would expect it to max out the number of waiting requests and then sit. The web server should still be able to communicate. I'll do a few tests to check this. Thanks for the lead.