- Welcome from the Chair
- Ohio State ECE At-A-Glance
- Contact Us
- Visit Us
- 5-year Strategic Plan
- Industrial Advisory Board
- ECE Outreach Program
- Administrative & Student Resources (internal)
- Job Openings in the Department
- Computer and IT Resources
Student Account Policies
RCC4 Policy for Intended Use
The student computing laboratories of The Department of Electrical & Computer Engineering (herein referred to as ER4), are intended to be used by students enrolled in, or taking classes from, The Department of Electrical & Computer Engineering. The facilities are provided to facilitate the assignments of ECE classes and related departmental requirements.
Use of the facilities for any purposes banned by The Ohio State University, The College of Engineering, or The Department of Electrical & Computer Engineering, including but not necessarily limited to personal monetary gain and violations of the University policies on sexual harassment (see Section II.D.5 of this pdf document for an example of applicable University policy), is expressly prohibited. Violation of this policy can result in the immediate revocation of account privileges and other actions as may be warranted.
Personal use of idle systems for activities not banned by the above policies (such as completing non-ECE homework, personal email, and Internet access) is permitted when the labs are less than 3/4 full, provided all other ER4 policies are satisfied. Regardless of lab usage, personal use of the ER4 systems must be terminated at the request of a lab consultant or site staff member.
If you have any question as to whether your use of the facilities might infringe upon this policy, please direct an email to the site staff (ENGfirstname.lastname@example.org) BEFORE engaging in such activities.
Computer Account Creation
All students enrolled in Electrical & Computer Engineering courses are eligible for an account on the ER4 computers. Accounts are created automatically, at the start of each quarter, based on class rosters. Late registration may lead to late account creation.
All student email is forwarded to BuckeyeMail.
Expiration of ECE Major Accounts
An Electrical & Computer Engineering major's account will be scheduled for deletion approximately one year after the student schedules his/her last ECE class. Thus if a student's last ECE class is in SP14, that account will be scheduled for deletion at some point during SP15.
Expiration of Non ECE Major Accounts
Students who are not enrolled in an Electrical & Computer Engineering major will lose their accounts as soon as they are no longer enrolled in an ECE course.
Locking of Accounts
A user's account may be locked at any time if deemed necessary by the site staff.
Suspension of Account Privileges
The site manager can restrict access to an account if such action is necessary to ensure the health of the computing environment. Such conditions may include, but are not limited to misuse of any part of the system or facilities, inappropriate use of the computing systems or violation of policy as defined by the department's Computing Committee, and any threat to the computing environment which appears to involve the user account.
The Computing Committee has final say in any matter regarding permanent suspension of account privileges. The site manager, at his option, may require a statement from the chair of the committee before reinstating account privileges.
It is the policy of the Department of Electrical & Computer Engineering that students who have current accounts in the Learning Technology Fee (LTF) labs will be granted keycard access to both the LTF computing laboratories and to the buildings which house those labs.
Keycard access control lists are generated each and every quarter based on SIS mined enrollment information. SIS reports are pulled the week before classes begin and then again in the first and third week of the quarter. These access control lists are then submitted to the University agency which controls the keycard readers.
If your keycard is not working...
- and it is the quarter break or the first week of the quarter, rosters may not have been processed yet. Individual keycard requests will not be processed before that time.
- and you registered late for classes, please wait before you submit your keycard request. We will rerun keycard lists in the third week of the quarter and you will be granted access at that time.
- and you are not currently taking an ECE class, then you will not have appeared on the SIS reprots from which access is granted. ECE students who pay the Engineering Computing fee, regardless of the ECE enrollment status, qualify for keycard access. If you believe you fall into this category, send a note to ENGemail@example.com and provide detailed information about your situation.
- and you have been patient and still don't have access, send an email to ENGfirstname.lastname@example.org with a subject line of "Keycard Request". In the body of the message include your Name as it is registered with the University, your EMPLID, your OSU Name.Number pairing, the lab/door you are unable to access and the date and time you attempted to access the lab/door. We will verify your enrollment against the rosters and then submit your information to keycard control. You will get an email from the site staff letting you know that this has been done. Keycard control may take up to two business days to process a request, though they are often much quicker. Try you card periodically over that period of time to see if it works.
- and you have submitted a request to site and your card is still not working two business days after you have been informed by Site that your information has been forwarded to keycard control, send an email to ENGemail@example.com with a subject of "Keycard: Continuing Access Problem". Again include the information detailed above. This time also include the date and time that you most recently tried to access two different card readers and list which two card readers you tried. This information will be sent to keycard control for their diagnostics.
All usage policies that apply to the Unix labs also apply to the PC labs. Thus no eating or drinking anything other than water in secured containers, is allowed in the labs, and the machines are only to be used for ECE classwork, etc.
System Modifications: Any modifications to the system, be it through modification to the registry or to system files is absolutely forbidden. The systems are set up to run as multi-user workstations and as such are not to be modified by individuals. If you feel that a system modification is required for your scholastic works, please send email to ENGfirstname.lastname@example.org, and we will take it under advisement.
Multiple Processes: Unlike the HPs, there are no remote users on the ER4 PC systems. Thus, there are no limits on the number of processes that you run (limited to one machine). However, please note that resources on any machine are finite, and the more you run, the slower any given single task will be performed. For best performance from the PCs, please only run what you have to.
Screen Locks: Please lock your terminal if you are stepping away from it. To do so, bring up the Windows Security Window (by pressing
Ctrl-Alt-Del) and select
Lock Computer. Note that PCs are only to be locked for short periods of time... don't exceed 10 minutes or you may be logged off.
Printing: the same printing policies apply to the ER4 PCs as to the Unix systems. The quota system is common between the two systems. Using the printer in the PC lab will count against your Unix quota and vice-versa.
File Storage: all users have 2.0GB of storage space in their home accounts. This storage is deemed sufficient for student academic purposes. It can be reached as the Z drive. Note: for most users (you should know if you are an exception), your ER4 Windows Desktop, My Documents, and Application Data folders are all redirected into folders of those same names on your Z drive. So files saved on your desktop, count against your quote.
Software Limitations: users are not to install any software on the ER4 systems. This includes installing software in your home directories (Z drive) so that they can be run on the system. This most specifically includes networked programs like chat, file sharing, and instant messaging systems. Violators of this policy will loose account privileges. Requests for software related to academic pursuits should be made to the Site staff.
Games, Chate and Instant Messaging: The ER4 PCs are to be used for school work only. Any extraneous use should be restricted to off-peak times, and should be restricted to programs installed by the systems administrators (see above). If asked by a staff member, or even by another student, non-class related work should be suspended immediately.
File Sharing: the installation and/or use of file sharing software including but not limited to those of the P2P type (ie: Kaza, EDonkey, etc) are explicit violations of University and Departmental policy (both in the student labs and on University Networks in general). Violations may result in loss of account and network-access privileges.
Rebooting: Sometimes PCs have to be rebooted. It's just the nature of these systems. However, such reboots should only be performed by ER4 staff. If you feel your PC needs to be rebooted, please see the student consultant in CL260. Please do not reboot it yourself.
Printing in the student labs (ER4) are on a cost recovery basis. The department does not collect any money beyond actual cost. There is no revenue generated through this program.
Single Sided: $0.06
Double Sided: $0.10
Q: How do I print?
To print in the student fee lab, a user submits a job to the print queue for the lab of choice. The user will then go to the pay-station next to the printers in the given lab and swipe their BuckID. A list of jobs in the queue will be displayed and you can select which job you wish to print. Appropriate funds are deducted from the card at that time.
Q: What if I print the wrong job?
If you accidentally print the wrong job, and there is no quick reasonable exchange with the person whose job you printed, then please go to the UniPrint refund web page,
Q: What if something is wrong with the printed pages?
If something is wrong with your printout (wrinkled paper, bad toner, etc...) please go to the UniPrint refund web page,
Q: What if my print job is not showing up in the print queue on the pay station?
This may be a UniPrint issue or it may be an ECE issue. If it is during normal business hours, we recommend that you see a lab consultant or contact ENGemail@example.com. Outside those hours you can call UniPrint (292-2000), but they may not be able to help if it is an ECE issue.
Q: What do I do if the printer is out of paper or toner?
First, please see if you can find a consultant. If one is not available you can either send email to ENGfirstname.lastname@example.org or call UniPrint (292-2000).
Q: Can I print from OSUWIRELESS?
Yes. Please see http://uniprint.osu.edu/services/wireless.aspx for details. Note for non-ECE readers: while it is true that any OSUWIRELESS user can print to these printers, the labs that contain the printers have limited access and so should not be used unless you already have access to those labs.
This policy is in place to ensure the fair distribution of computing resources among the many persons using them.
Statement of Policy
- Users are entitled to log into the console of one, and only one, workstation.
- Users who are logged into the console of a Windows-based workstation may make a remote connection to one Unix system.
- Users may not run more than one remote or background process at a time.
- Processes that are submitted to the remote access cluster may be run at normal process priority.
- Processes that are submitted to Unix systems that permit on-console sessions or processes that are left behind as background processes on such systems, must be run at the lowest possible priority.
- Processes such as web browsers and full-blown CDE or KDE sessions may not be run remotely on the ER4 systems. All such functionality is available on your local system and does not consume network or ER4 resources.
- The process priority requirements of this policy are not applied to such processes as shells or SSH connections. Those processes are recognized as required overhead. The policy is intended to apply to resource-intense processes such as (but not limited to) Matlab, Mentor Graphics and Cadence.
- A remote process is defined as any process running on a system on which the user is not logged into the console.
- A back-grounded process, in the context of this policy, is defined as a process that is started during an interactive console session but continues to run after the user logs out of that session.
- On-console capable systems are currently defined as all ER4 Red Hat workstations.
Users found in violation of this policy may have their processes terminated without warning. Repeated violations may result is suspension of account privileges.
It is recognized that at certain times the ER4 facilities are under-utilized. At these times exceptions may be made to the one-process limitation. Submit a request to the site staff by sending email to ENGemail@example.com if you wish to apply for an exception. All requests for exceptions must be approved prior to processes initialization.
Methods of Process Control
The best tool for listing Unix processes is the
ps command. To get a "long" listing of all your own processes, including such information as process priority, use the following command:
ps -flu username
The returned information will look something like this:
er4rh016-juodvalk> ps -flu juodvalk F S UID PID PPID C PRI NI ADDR SZ WCHAN STIME TTY TIME CMD 5 S juodvalk 2923 2919 0 75 0 - 2165 - 13:26 ? 00:00:00 sshd: juodvalk@pts/1 0 S juodvalk 2924 2923 0 75 0 - 1871 rt_sig 13:26 pts/1 00:00:00 -tcsh 0 T juodvalk 2954 2924 0 76 0 - 2316 finish 13:27 pts/1 00:00:00 vim Untitled1..doc 0 R juodvalk 2959 2924 0 77 0 - 953 - 13:27 pts/1 00:00:00 ps -flu juodvalk
Of interest here are the "PID" which is the process identifier and is used when interacting with the process, the "NI" value which tells how "nice" a process is, and the "COMD" value which identifies the running process by name.
To be in compliance with this policy, any resource intense process should be set to the lowest priority level possible. This is accomplished by raising the "nice" value. In this case, the nicer a process is, the less resources it will consume. Of the four processes listed above, PID 2924 is the shell process and PID 2923 is the SSH daemon. Both of these processes are accepted overhead and may run as is. PID 2959 is the ps command used to get that information and also may run as is. vi is a simple text editor and would normally not be treated as a resource intense package, but for the purpose of this demonstration we will treat it as though it were.
The current "nice" value of PID 2954 is "0". This is the default nice value for all user initiated processes. To be as nice as possible, this value should be "19". This change in value is made by the "renice" command. Its man pages may be referenced for full details, but to simply change the nice value of a process so that it complies with this policy, the following command can be used:
er4rh016-juodvalk> renice 20 2954 2954: old priority 0, new priority 19
Having executed that command, the new priority can be seen with a second ps invocation:
er4rh016-juodvalk> ps -flu juodvalk F S UID PID PPID C PRI NI ADDR SZ WCHAN STIME TTY TIME CMD 5 S juodvalk 2923 2919 0 75 0 - 2165 - 13:26 ? 00:00:00 sshd: juodvalk@pts/1 0 S juodvalk 2924 2923 0 75 0 - 1871 rt_sig 13:26 pts/1 00:00:00 -tcsh 0 T juodvalk 2954 2924 0 99 19 - 2316 finish 13:27 pts/1 00:00:00 vim Untitled1..doc 0 R juodvalk 3000 2924 0 77 0 - 1023 - 13:28 pts/1 00:00:00 ps -flu juodvalk
It can be seen that the NI column now shows a value of 19 for PID 2954. This is the desired result.
To start a process with an initial NI value of 19, the "nice" command can be used at the time of invocation. The following is used to start an
emacs process at an already nice level:
er4rh016-juodvalk> nice +20 xterm -ls &  3039
The emacs process can now be shown to have started with the correct nice value:
er4rh016-juodvalk> ps -flu juodvalk F S UID PID PPID C PRI NI ADDR SZ WCHAN STIME TTY TIME CMD 5 S juodvalk 2923 2919 0 75 0 - 2165 - 13:26 ? 00:00:00 sshd: juodvalk@pts/1 0 S juodvalk 2924 2923 0 75 0 - 1872 rt_sig 13:26 pts/1 00:00:00 -tcsh 0 T juodvalk 2954 2924 0 99 19 - 2316 finish 13:27 pts/1 00:00:00 vim Untitled1..doc 0 S juodvalk 3039 2924 0 96 19 - 1258 - 13:31 pts/1 00:00:00 xterm -ls 0 R juodvalk 3042 2924 0 77 0 - 841 - 13:31 pts/1 00:00:00 ps -flu juodvalk
Questions and Comments
Questions about the enforcement of this policy may be sent to ENGfirstname.lastname@example.org.
Questions or comments about the content of this policy may be sent to email@example.com.
At any time that a workstation is left untended, regardless of duration, that workstation must have its screen locked.
No machine should be left locked for more than a few minutes. Trips to the printers or restrooms or to make a short phone call or other similar functions may be considered valid reasons to leave a machine locked. A break for a meal, or to attend class, will not. A user should log out and allow others to use the machine in such cases.
Any screen left locked for an extended period of time may have that lock broken. The user's processes will be terminated and the user logged out. The general definition of an "extended" period of time is 10 minutes, but this may vary as a situation warrants.
Note bene: This policy covers all workstations within the Student Fee Labs, including Unix and Windows based systems.