Thanks Alan and Barry. Both your ideas seem sensible - and I shall pass them onto the systems administrator. We had thought that the problem could be coming from the "save" and Barry's explanation makes a lot of sense. Shall try today saving to the local machine and see what happens.
Diana > Carroll, Barry <[EMAIL PROTECTED]> wrote: > > Hello, Diana, > > I have had a little experience with networking problems. Here's my take > on your situation. > > Regards, > > > > Date: Tue, 15 Aug 2006 11:19:35 +1000 > > From: Diana Hawksworth <[EMAIL PROTECTED]> > > Subject: Re: [Tutor] Python on network problems > > To: Alan Gauld <[EMAIL PROTECTED]> > > Cc: tutor@python.org > > Message-ID: <[EMAIL PROTECTED]> > > Content-Type: text/plain > > > <<snip>> > > > > We are running Windows XP. The students log in to a network server > that > > allows them access to their user accounts as well as various group > > folders. We have 4 rooms full of computers - but Python is installed > on > > each workstation in this room only ie, it is "active" in this room > only. > > It is not on the network and no other computer rooms have access to > it. > > The students in this room save their Python files to a networked > "user" > > account - as they do with all their other files. > > > > From your description, I gather that a single computer provides > authentication service and file service to the entire network. Is this > correct? If so, that machine is a single point of failure in your > network. If it hangs for any reason, the entire network "goes away". > > > Two failures have occurred. > > > > The first has been intermittent and to individual students only at > rare > > times. A student will attempt to start IDLE - and nothing will > happen. > > Sometimes, changing that student's log in user name will solve the > > problem, and he then has access to Python again. > > > > I don't haven't used IDLE that much, so Alan's ideas are more reliable > than mine here: > > >> That could be a local machine/user setup issue. > >> Given the various issues with IDLE and firewalls I might > >> look at the firewall settings on the Python PCs and make > >> sure IDLE is happy with them. > > > The 2nd is more pervasive, and that is, whenever I have the class > working > > with Python - the entire school network becomes inoperable, and the > system > > administrator needs to reboot it again. Because we have been working > on > > Python each time this has happened, Python is being blamed for the > system > > failure. Inoperable - no one is able to open any files in any program, > > save any work they have been working on, open files - or even log in > if > > they haven't already. The whole system is " frozen", from the office > to > > every other computer in the school. > > > Now I am inclined to think it is not a Python problem at all. Python > is > > locally and individually installed on computers in this room only. It > has > > no network access at all - apart from files being saved in networked > user > > accounts. > > > > >> The only slight possibility is if any of the students are > >> writing code that accesses a networked folder, to open > >> a file say, and is causing some high volume network traffic. > > I think Alan is right here, too, and here's why. (Python internals > gurus, please correct any bad assumptions in the following.) Lab #4 is > full of users running Python programs. The interpreter is running on > each local machine, but the program (and data) files are all stored on > the lone network file server. Since Python programs are executed by the > interpreter, they access file storage more heavily that compiled > programs do. So, every time any of the (15, 20, 25?) computers in the > Python lab needs a file, or needs to save a file, it sends a request to > that one computer. The potential bottleneck is obvious. > > I think the network server's capacity is being exceeded in some way. > When this happens, instead of degrading service gracefully (e.g. > rejecting a request and instructing the client to try again later) the > server is getting lost somehow and hanging, causing the failure modes > you describe. > > Here are some areas for your network administrator to investigate: > > * maximum number of concurrent disk access requests, > * maximum number of open files, > * file server disk usage, > * file server disk fragmentation, > * server processor utilization, > * network bandwidth utilization, > * other limits imposed by the networking software or the > server's hardware. > > > What I would like to know is if anyone else has had a similar problem > - > > and it has been proven that Python is the cause? If so - how was the > > problem solved? > > > > The best solution (IMHO) is also the most expensive: add a redundant > server to your network. This would eliminate the single point of > failure weakness and reduce the load per server. Also, is one server > should hang or fail for any other reason, the duplicate server can keep > the network running while the failed machine is rebooted, repaired, etc. > > > If possible, I would recommend using a Unix clone as your server's OS > instead of Windows. Even Linux, which is available free of charge, > provides a more stable platform for a network server than does Windows. > This is relatively easy, especially if your network is based on TCP/IP. > Many Windows intranets use Unix/Linux servers. The biggest obstacle, in > many cases, is the learning curve required of the network administrator. > > > > Be grateful for any advice - and hope I have made the situation > clearer > > now. > > > > Diana > > > > HTH > > Barry > [EMAIL PROTECTED] > 541-302-1107 > ________________________ > We who cut mere stones must always be envisioning cathedrals. > > -Quarry worker's creed _______________________________________________ Tutor maillist - Tutor@python.org http://mail.python.org/mailman/listinfo/tutor
