https://wiki.archlinux.org/api.php?action=feedcontributions&user=PeterL&feedformat=atomArchWiki - User contributions [en]2024-03-29T11:16:30ZUser contributionsMediaWiki 1.41.0https://wiki.archlinux.org/index.php?title=Acer_Aspire_3000_(300x)&diff=330320Acer Aspire 3000 (300x)2014-08-14T20:47:32Z<p>PeterL: sisfb module is no longer available in latest kernel</p>
<hr />
<div>[[Category:Acer]]<br />
This page was created using knowledge collected while playing with Acer Aspire 3003 WLMi, but it will be probably compatible with other 300x Aspires. You can add your laptops to the compatibility list.<br />
<br />
== Compatibility list ==<br />
* [[Acer Aspire 3003 WLMi]]<br />
* [[Acer Aspire 3000 ZL5]]<br />
<br />
== lspci ==<br />
00:00.0 Host bridge: Silicon Integrated Systems [SiS] 760/M760 Host (rev 03)<br />
00:01.0 PCI bridge: Silicon Integrated Systems [SiS] SG86C202<br />
00:02.0 ISA bridge: Silicon Integrated Systems [SiS] SiS963 [MuTIOL Media IO] (rev 25)<br />
00:02.1 SMBus: Silicon Integrated Systems [SiS] SiS961/2 SMBus Controller<br />
00:02.5 IDE interface: Silicon Integrated Systems [SiS] 5513 [IDE]<br />
00:02.6 Modem: Silicon Integrated Systems [SiS] AC'97 Modem Controller (rev a0)<br />
00:02.7 Multimedia audio controller: Silicon Integrated Systems [SiS] AC'97 Sound Controller (rev a0)<br />
00:03.0 USB Controller: Silicon Integrated Systems [SiS] USB 1.1 Controller (rev 0f)<br />
00:03.1 USB Controller: Silicon Integrated Systems [SiS] USB 1.1 Controller (rev 0f)<br />
00:03.2 USB Controller: Silicon Integrated Systems [SiS] USB 2.0 Controller<br />
00:04.0 Ethernet controller: Silicon Integrated Systems [SiS] SiS900 PCI Fast Ethernet (rev 91)<br />
00:06.0 CardBus bridge: Texas Instruments PCI1410 PC card Cardbus Controller (rev 02)<br />
00:0b.0 Network controller: Broadcom Corporation BCM4318 [AirForce One 54g] 802.11g Wireless LAN Controller (rev 02)<br />
00:18.0 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] HyperTransport Technology Configuration<br />
00:18.1 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Address Map<br />
00:18.2 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] DRAM Controller<br />
00:18.3 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Miscellaneous Control<br />
01:00.0 VGA compatible controller: Silicon Integrated Systems [SiS] 661/741/760 PCI/AGP or 662/761Gx PCIE VGA Display Adapter<br />
<br />
== /etc/X11/xorg.conf ==<br />
Before editing xorg.conf, you will need to install few drivers:<br />
<br />
xf86-input-synaptics 0.99.3-1<br />
synaptics driver for notebook touchpads<br />
xf86-video-sis 0.10.1-1 (xorg-video-drivers)<br />
X.org SiS video driver<br />
<br />
You can use this xorg.conf to get your [[Synaptics]] touchpad, USB mouse (or optionally [[wacom]] tablet) and SiS graphical adapter with [[sisctrl]] support working.<br />
<br />
== FBDev (SiSFB FrameBuffer) ==<br />
<br />
sisfb module is no longer available in the latest standard kernels, an alternative is to use the [[uvesafb]] module<br />
<br />
=== /boot/grub/menu.lst ===<br />
If you want have nicer screen resolutin in [[framebuffer]] (textmode), then you have to add this configuration in [[/boot/grub/menu.lst]].<br />
<br />
==== sisfb ====<br />
<br />
If you want to specify your own resolution using custom video driver, then you have to replace ''vga'' option with ''video'' option. For example if you want to user resolution 1280x800 with 32-bit color depth at 76Hz (which is recommended for [[Acer Aspire 3000]]) then you can use this option:<br />
video=sisfb:mode:1280x800x32,rate:76<br />
You can also play with memory consumption like this, but its not needed and it can cause some problems, if you do not know what are you doing:<br />
video=sisfb:mode:1280x800x24,mem:12288,rate:76<br />
<br />
==== vga ====<br />
Basically you can append this option to the [[kernel parameters]]. This should work on any VGA compliant graphical adapter if it will have enough resources. But it will look ugly on widescreens, LCDs and similar, if they do not match the exact VGA resolution and it is better to use ''video=...'' option.<br />
vga=791<br />
If you do not like 791 mode, then you can use this:<br />
vga=ask<br />
And you will be informed about all modes compatible with your system configuration after reboot.<br />
<br />
== /etc/mkinitcpio.conf ==<br />
You can also add sisfb module to [[mkinitcpio]] by adding it to the /etc/mkinitcpio.conf and regenerating mkinitcpio. This will allow sisfb get loaded before filesystems are mounted, so you will get nice screen resolution much earlier than without it.<br />
MODULES="pata_acpi pata_sis ata_generic scsi_mod '''sisfb''' ..."<br />
<br />
== Related articles ==<br />
* [[xf86-video-sis]]<br />
* [[Wireless network configuration#b43]]<br />
* [[Touchpad Synaptics]]<br />
* Misc.<br />
** [[CPU frequency scaling]]<br />
** [[Pm-utils]]<br />
** [[Laptop Mode Tools]]<br />
** [[Wacom Tablet]]</div>PeterLhttps://wiki.archlinux.org/index.php?title=Acer_Aspire_3000_(300x)&diff=330318Acer Aspire 3000 (300x)2014-08-14T20:46:07Z<p>PeterL: /* FBDev (SiSFB FrameBuffer) */</p>
<hr />
<div>[[Category:Acer]]<br />
This page was created using knowledge collected while playing with Acer Aspire 3003 WLMi, but it will be probably compatible with other 300x Aspires. You can add your laptops to the compatibility list.<br />
<br />
== Compatibility list ==<br />
* [[Acer Aspire 3003 WLMi]]<br />
* [[Acer Aspire 3000 ZL5]]<br />
<br />
== lspci ==<br />
00:00.0 Host bridge: Silicon Integrated Systems [SiS] 760/M760 Host (rev 03)<br />
00:01.0 PCI bridge: Silicon Integrated Systems [SiS] SG86C202<br />
00:02.0 ISA bridge: Silicon Integrated Systems [SiS] SiS963 [MuTIOL Media IO] (rev 25)<br />
00:02.1 SMBus: Silicon Integrated Systems [SiS] SiS961/2 SMBus Controller<br />
00:02.5 IDE interface: Silicon Integrated Systems [SiS] 5513 [IDE]<br />
00:02.6 Modem: Silicon Integrated Systems [SiS] AC'97 Modem Controller (rev a0)<br />
00:02.7 Multimedia audio controller: Silicon Integrated Systems [SiS] AC'97 Sound Controller (rev a0)<br />
00:03.0 USB Controller: Silicon Integrated Systems [SiS] USB 1.1 Controller (rev 0f)<br />
00:03.1 USB Controller: Silicon Integrated Systems [SiS] USB 1.1 Controller (rev 0f)<br />
00:03.2 USB Controller: Silicon Integrated Systems [SiS] USB 2.0 Controller<br />
00:04.0 Ethernet controller: Silicon Integrated Systems [SiS] SiS900 PCI Fast Ethernet (rev 91)<br />
00:06.0 CardBus bridge: Texas Instruments PCI1410 PC card Cardbus Controller (rev 02)<br />
00:0b.0 Network controller: Broadcom Corporation BCM4318 [AirForce One 54g] 802.11g Wireless LAN Controller (rev 02)<br />
00:18.0 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] HyperTransport Technology Configuration<br />
00:18.1 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Address Map<br />
00:18.2 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] DRAM Controller<br />
00:18.3 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Miscellaneous Control<br />
01:00.0 VGA compatible controller: Silicon Integrated Systems [SiS] 661/741/760 PCI/AGP or 662/761Gx PCIE VGA Display Adapter<br />
<br />
== /etc/X11/xorg.conf ==<br />
Before editing xorg.conf, you will need to install few drivers:<br />
<br />
xf86-input-synaptics 0.99.3-1<br />
synaptics driver for notebook touchpads<br />
xf86-video-sis 0.10.1-1 (xorg-video-drivers)<br />
X.org SiS video driver<br />
<br />
You can use this xorg.conf to get your [[Synaptics]] touchpad, USB mouse (or optionally [[wacom]] tablet) and SiS graphical adapter with [[sisctrl]] support working.<br />
<br />
== FBDev (SiSFB FrameBuffer) ==<br />
<br />
sisfb module is no longer available in the latest kernels, an alternative is to use the [[uvesafb]] module<br />
<br />
=== /boot/grub/menu.lst ===<br />
If you want have nicer screen resolutin in [[framebuffer]] (textmode), then you have to add this configuration in [[/boot/grub/menu.lst]].<br />
<br />
==== sisfb ====<br />
<br />
If you want to specify your own resolution using custom video driver, then you have to replace ''vga'' option with ''video'' option. For example if you want to user resolution 1280x800 with 32-bit color depth at 76Hz (which is recommended for [[Acer Aspire 3000]]) then you can use this option:<br />
video=sisfb:mode:1280x800x32,rate:76<br />
You can also play with memory consumption like this, but its not needed and it can cause some problems, if you do not know what are you doing:<br />
video=sisfb:mode:1280x800x24,mem:12288,rate:76<br />
<br />
==== vga ====<br />
Basically you can append this option to the [[kernel parameters]]. This should work on any VGA compliant graphical adapter if it will have enough resources. But it will look ugly on widescreens, LCDs and similar, if they do not match the exact VGA resolution and it is better to use ''video=...'' option.<br />
vga=791<br />
If you do not like 791 mode, then you can use this:<br />
vga=ask<br />
And you will be informed about all modes compatible with your system configuration after reboot.<br />
<br />
== /etc/mkinitcpio.conf ==<br />
You can also add sisfb module to [[mkinitcpio]] by adding it to the /etc/mkinitcpio.conf and regenerating mkinitcpio. This will allow sisfb get loaded before filesystems are mounted, so you will get nice screen resolution much earlier than without it.<br />
MODULES="pata_acpi pata_sis ata_generic scsi_mod '''sisfb''' ..."<br />
<br />
== Related articles ==<br />
* [[xf86-video-sis]]<br />
* [[Wireless network configuration#b43]]<br />
* [[Touchpad Synaptics]]<br />
* Misc.<br />
** [[CPU frequency scaling]]<br />
** [[Pm-utils]]<br />
** [[Laptop Mode Tools]]<br />
** [[Wacom Tablet]]</div>PeterLhttps://wiki.archlinux.org/index.php?title=Initscripts/rc.conf&diff=233753Initscripts/rc.conf2012-11-04T22:55:12Z<p>PeterL: correction /var/lib/hwclock/adjtime no longer exists</p>
<hr />
<div>[[Category:Boot process]]<br />
[[cs:Rc.conf]]<br />
[[de:rc.conf]]<br />
[[es:Rc.conf]]<br />
[[fr:rc.conf]]<br />
[[it:Rc.conf]]<br />
[[nl:Rc.conf]]<br />
[[ro:rc.conf]]<br />
[[ru:Rc.conf]]<br />
[[sr:Rc.conf]]<br />
[[tr:rc.conf]]<br />
[[uk:Rc.conf]]<br />
[[zh-CN:Initscripts/rc.conf]]<br />
{{Lowercase title}}<br />
{{ic|/etc/rc.conf}} is the configuration file for {{pkg|initscripts}}. It configures what daemons to start at boot, the basic network daemon, and certain aspects of hardware discovery.<br />
<br />
==Overview==<br />
<br />
This is what a typical {{ic|rc.conf}} file looks like on an up-to-date Arch install. ([https://projects.archlinux.org/initscripts.git/tree/rc.conf current version]):<br />
<br />
{{hc|/etc/rc.conf|<nowiki><br />
#<br />
# /etc/rc.conf - configuration file for initscripts<br />
#<br />
# Most of rc.conf has been replaced by various other configuration<br />
# files. See archlinux(7) for details.<br />
#<br />
# For more details on rc.conf see rc.conf(5).<br />
#<br />
<br />
DAEMONS=()<br />
<br />
# A reasonable DAEMONS array when using sysvinit is:<br />
# DAEMONS=(syslog-ng network crond)<br />
#<br />
# When using systemd, it is recommended to only enable daemons that<br />
# do not have native systemd service files.<br />
<br />
# Storage<br />
#<br />
# USEDMRAID="no"<br />
# USELVM="no"<br />
<br />
# Network<br />
#<br />
# interface=<br />
# address=<br />
# netmask=<br />
# gateway=<br />
</nowiki>}}<br />
<br />
== New configuration file ==<br />
In the past, this file also used to contain configurations for other parts of the system. If you are using initscripts as your init system, {{ic|/etc/rc.conf}} configures which daemons to start during boot-up and some networking and storage information.<br />
<br />
{{Note|Using the legacy configuration options in {{ic|/etc/rc.conf}} for system configuring still works (for now) with the default init system, but the new configuration files take precedence and using them is recommended. The new files will also work for configuring [[systemd]]. See [[Systemd#Native_configuration]]}}<br />
<br />
{| class="wikitable"<br />
|-<br />
! scope="col"| Configuration<br />
! scope="col"| Configuration file(s)<br />
! scope="col"| Legacy [https://projects.archlinux.org/initscripts.git/tree/rc.conf?id=97f0cd6751e8d22c14d7492cdc2186cf41157ba6 rc.conf] section<br />
|-<br />
| align="center"|Hostname<br />
| align="left"|{{ic|/etc/hostname}}<br />
{{ic|/etc/hosts}}<br />
| align="center"|{{ic|NETWORKING}}<br />
|-<br />
| align="center"|Console fonts and keymap<br />
| align="left"|{{ic|/etc/vconsole.conf}}<br />
| align="center"|{{ic|LOCALIZATION}}<br />
|-<br />
| align="center"|Locale<br />
| align="left"|{{ic|/etc/locale.conf}}<br />
{{ic|/etc/locale.gen}}<br />
| align="center"|{{ic|LOCALIZATION}}<br />
|-<br />
| align="center"|Timezone<br />
| align="left"|{{ic|/etc/localtime}}<br />
| align="center"|{{ic|LOCALIZATION}}<br />
|-<br />
| align="center"|Hardware clock<br />
| align="left"|{{ic|/etc/adjtime}}<br />
| align="center"|{{ic|LOCALIZATION}}<br />
|-<br />
| align="center"|Kernel modules<br />
| align="left"|{{ic|/etc/modules-load.d/}}<br />
| align="center"|{{ic|HARDWARE}}<br />
|-<br />
| align="center"|Daemons<br />
| align="left"|{{ic|/etc/rc.conf}}<br />
| align="center"|{{ic|DAEMONS}}<br />
|-<br />
| align="center"|Wired network<br />
| align="left"|{{ic|/etc/rc.conf}}<br />
| align="center"|{{ic|NETWORKING}}<br />
|}<br />
<br />
Configuration files can simply be created if they do not exist already and you wish to change the defaults.<br />
<br />
==Daemons==<br />
<br />
; [[Daemons|DAEMONS]]<br />
: {{Note|Systemd can handle most daemons in Arch. Consider starting daemons with systemd instead. See [[systemd]] for more information.}}<br />
: A space-separated list of scripts located in {{ic|/etc/rc.d/}} which are started during the boot process. Usually you do not need to change the defaults to get a running system, but you are going to edit this array whenever you install system services like {{ic|sshd}}, and want to start these automatically during boot-up. This is basically Arch's way of handling what others handle with various symlinks to an {{ic|init.d}} directory. For more info see: [[Writing rc.d scripts]]<br />
:# If a script name is prefixed with a bang ({{ic|!}}), it is not executed. <br />
:# If a script is prefixed with an "at" symbol ({{ic|@}}), then it will be executed in the background, i.e. the startup sequence will not wait for successful completion before continuing.<br />
: Example:<br />
: {{bc|<nowiki>DAEMONS=(@syslog-ng !network net-profiles crond sshd)</nowiki>}}<br />
: {{Note|The order in which the daemons are listed is important as they are loaded in that order.}}<br />
<br />
==Hardware==<br />
; USEDMRAID: Scan for FakeRAID (dmraid) Volumes at startup (runs {{ic|dmraid -i -ay}}). <br />
; USELVM: Scan for [[LVM]] volume groups at start-up, which is required if you use LVM. Setting to {{ic|YES}} runs {{ic|vgchange --sysinit -a y}} (handled by activate_vgs() function) during sysinit.<br />
; {{Note|USEBTRFS is no longer needed, as it is taken care of by udev.}}<br />
<br />
=== Interface configuration ===<br />
{{ic|rc.conf}} only supports the configuration of a single interface. For the configuration of multiple interfaces or other advanced network configurations like bridging, use [[netcfg]].<br />
<br />
; interface: name of device (required)<br />
; address: IP address (leave blank for DHCP)<br />
; netmask: subnet mask (ignored for DHCP) (optional, defaults to 255.255.255.0)<br />
; broadcast: broadcast address (ignored for DHCP) (optional)<br />
; gateway: default route (ignored for DHCP)<br />
<br />
{{hc|Static IP Example|<nowiki>interface=eth0<br />
address=192.168.0.2<br />
netmask=255.255.255.0<br />
broadcast=192.168.0.255<br />
gateway=192.168.0.1</nowiki>}}<br />
{{hc|DHCP example|<nowiki>interface=eth0<br />
address=<br />
netmask=<br />
gateway=</nowiki>}}<br />
{{Note|Make sure to add {{ic|network}} to {{ic|DAEMONS}} {{bc|<nowiki>DAEMONS=(... network sshd)</nowiki>}}<br />
or, if using [[netcfg]], add {{ic|net-profiles}} {{bc|<nowiki>DAEMONS=(... !network net-profiles sshd)</nowiki>}}<br />
}}<br />
<br />
==Modules==<br />
; MODULES: {{Warning|Modules to be autoloaded at boot are now specified in {{ic|/etc/modules-load.d/}}, and modules to be blacklisted are now specified in {{ic|/etc/modprobe.d/}}.}}<br />
Modules to load at boot-up in addition to auto-loaded ones, to do this see [[Kernel modules#Loading]], and to blacklist modules, see [[Kernel modules#Blacklisting]].<br />
: {{Note|{{ic|MOD_AUTOLOAD}} is deprecated as of {{Pkg|initscripts}} 2011.06.1-1, you can use [[udev]] rules to achieve the same effect.}}<br />
: {{Tip|Some modules may not be loaded in the order they are listed, as they might also be loaded on-demand by [[udev]]. For consistent network interface names between boots, create the [[Udev#Mixed_Up_Devices.2C_Sound.2FNetwork_Cards_Changing_Order_Each_Boot|appropriate udev rules]].}}<br />
<br />
==Localization==<br />
; [[TIMEZONE#Time_standard|HARDWARECLOCK]]: {{Warning|This setting is now configured in {{ic|/etc/adjtime}}.}} Specifies whether the hardware clock, which is synchronized from on bootup and to on shutdown, stores {{ic|UTC}} time, or the {{ic|localtime}}. If this value is not set, then the value stored by hwclock in {{ic|/var/lib/hwclock/adjtime}} is used instead. See [[Time]] for more information.<br />
:# {{ic|UTC}} makes sense because it greatly simplifies changing timezones and daylight savings time. Linux will change to-and-from DST, regardless of whether Linux was running at the time DST is entered or left.<br />
:# {{ic|localtime}} is necessary if you dual boot with an operating system that only stores {{ic|localtime}}, such as Windows. Linux will not adjust the time, operating under the assumption that your system may be a dual-boot system at that time and that the other OS takes care of the DST switch. If that was not the case, the DST change needs to be made manually.<br />
:# empty: fall back to the value in {{ic|/etc/adjtime}}, which defaults to UTC. This is recommended as other users of hwclock might change the adjtime file and hence cause rc.conf and adjtime to be out of sync<br />
:# any other value will result in the hardware clock being left untouched (useful for virtualization)<br />
; [[TIMEZONE]]: {{Warning|This setting is now configured by the {{ic|/etc/localtime}} symlink.}} Specifies your time zone. Possible time zones are the relative path to a zoneinfo file starting from the directory {{ic|/usr/share/zoneinfo}}. For example, a German timezone would be {{ic|Europe/Berlin}}, which refers to the file {{ic|/usr/share/zoneinfo/Europe/Berlin}}.<br />
; [[KEYMAP]]: {{Warning|This setting is now configured in {{ic|/etc/vconsole.conf}}.}} The keyboard layout you want to use. If you live in the US, you probably use qwerty, which is referred using us (default). The available keymaps are in {{ic|/usr/share/kbd/keymaps}}. {{Note|Please note that this setting is only valid for your TTYs, not any graphical window managers or X!}}<br />
<br />
; [[Fonts#Console_fonts|CONSOLEFONT]]: {{Warning|This setting is now configured in {{ic|/etc/vconsole.conf}}.}} Defines the console font to load with the {{ic|setfont}} program on boot-up (ter-v14b for example). Possible fonts are found in {{ic|/usr/share/kbd/consolefonts}} (only needed for non-US). {{ic|FONT}} in {{ic|/etc/vconsole.conf}} takes precedence. For more info see: [[Fonts#Console_fonts|Console fonts]]<br />
; [[Fonts#Console_fonts|CONSOLEMAP]]: {{Warning|This setting is now configured in {{ic|/etc/vconsole.conf}}.}} Defines the console map to load with the {{ic|setfont}} program on boot-up (8859-1_to_uni for example). Possible maps are found in {{ic|/usr/share/kbd/consoletrans}}. You will want to set this to a map suitable for your locale (8859-1 for Latin1, for example) if you use an utf8 locale above and use programs that generate 8-bit output. {{ic|FONT_MAP}} in {{ic|/etc/vconsole.conf}} takes precedence. {{Note|If using X11 for everyday work, note that this only affects the output of console applications.}}<br />
; [[LOCALE]]: {{Warning|This setting is now configured in {{ic|/etc/locale.gen}}. Run {{ic|locale-gen}} to update changes. The system-wide locale can be set in {{ic|/etc/locale.conf}}.}} This sets your system language, which will be used by all i18n-friendly applications and utilities. You can get a list of the available locales by running {{ic|locale -a}} from the command line. This setting's default is fine for US English users. The {{ic|LANG}} variable in {{ic|[[locale.conf|/etc/locale.conf]]}} takes precedence if it is set, and users of login shells that cannot source {{ic|/etc/rc.conf}}, should set that value instead.<br />
; DAEMON_LOCALE: {{Warning|This setting is obsolete.}} If set to yes, use {{ic|$LOCALE}} as the locale during daemon startup and during the boot process. If set to no, the '''C''' locale is used. Default value is yes.<br />
; USECOLOR: {{Warning|This setting is obsolete.}} Enable (or disable) colorized status messages during boot-up.<br />
<br />
==Networking==<br />
<br />
The HOSTNAME variable is deprecated, and the hostname is now set in {{ic|/etc/hostname}} (see {{ic|man 5 hostname}}).<br />
<br />
=== Network Persist ===<br />
The {{ic|NETWORK_PERSIST}} variable tells the system whether or not to skip network shutdown. This is required if your root device is on NFS. The default setting is "no".<br />
# default<br />
NETWORK_PERSIST="no"<br />
<br />
# NFS-based root device<br />
# NETWORK_PERSIST="yes"<br />
<br />
==GUI Frontends==<br />
This is a list of {{ic|/etc/rc.conf}} GUI front-ends, designed to provide a graphical interface to the {{ic|/etc/rc.conf}} file. The list includes GTK2-based software and Qt based software.<br />
<br />
{{Warning|None of these tools are officially supported by the Arch developers. Moreover, [[systemd]] is now the default init daemon, so {{ic|/etc/rc.conf}} is obsolete.}}<br />
<br />
===ArchLinux Daemon Manager GUI===<br />
ArchLinux Daemon Manager allows you to easily change settings in {{ic|/etc/rc.conf}} using GTK application aldm-gui or command-line application aldm.<br />
<br />
*Homepage: https://github.com/Harvie/ArchLinux-Daemon-Manager<br />
*AUR Package Details: {{AUR|aldm}}<br />
*Screenshots: http://img130.imageshack.us/img130/4200/aldmgui03.png<br />
<br />
===rcconf-settings===<br />
rcconf-settings is a tool designed for the Chakra GNU/Linux distribution but should also work on Arch Linux.<br />
<br />
* Homepage: http://gitorious.org/chakra/rcconf-settings<br />
* AUR Package Details: {{AUR|kcm-rcconf-settings}}<br />
* Screenshots: http://s2.subirimagenes.com/imagen/5986587instantnea1.png</div>PeterLhttps://wiki.archlinux.org/index.php?title=User:PeterL&diff=233747User:PeterL2012-11-04T22:21:51Z<p>PeterL: Created page with "Hi I'm Peter"</p>
<hr />
<div>Hi I'm Peter</div>PeterLhttps://wiki.archlinux.org/index.php?title=System_time&diff=233745System time2012-11-04T22:13:44Z<p>PeterL: /* Hardware clock and system clock */</p>
<hr />
<div>[[es:TIMEZONE]]<br />
[[fa:زمان]]<br />
[[fr:Horloge]]<br />
[[ru:Time]]<br />
[[zh-CN:Time]]<br />
[[Category:Mainboards and BIOS]] <!-- with regard to the hardware clock --><br />
[[Category:Daemons and system services]] <!-- as the basis/rationale for NTP --><br />
{{Article summary start}}<br />
{{Article summary text|This article provides an introduction to the concept of keeping time on computers in general, and describes how clocks are configured and managed in Arch Linux.}}<br />
{{Article summary heading|Related}}<br />
{{Article summary wiki|Network Time Protocol}}<br />
{{Article summary end}}<br />
<br />
In an operating system the time (clock) is determined by four parts: Time value, Time standard, Time Zone, and DST ('''D'''aylight '''S'''aving '''T'''ime if applicable). This article explains what they are and how to read/set them. To ''maintain'' accurate system time on a network see [[Network Time Protocol]].<br />
<br />
== Hardware clock and system clock ==<br />
<br />
A computer has two clocks that need to be considered: the "Hardware clock" and the "System/software clock". <br />
<br />
'''Hardware clock''' (a.k.a. the Real Time Clock (RTC) or CMOS clock) stores the values of: Year, Month, Day, Hour, Minute, and the Seconds. It does not have the ability to store the time standard (localtime or UTC), nor whether DST is used. <br />
<br />
'''System clock''' (a.k.a. the software clock) keeps track of: Time, Time Zone, and DST if applicable. It is calculated by the Linux kernel as the number of seconds since midnight January 1st 1970, UTC. The initial value of the system clock is calculated from the hardware clock, dependent on the contents of {{ic|/etc/adjtime}} (or for systems still using the old initscripts the value of the HARDWARECLOCK variable defined in {{ic|/etc/rc.conf}}). After boot-up has completed the system clock runs independently of the hardware clock. The Linux kernel keeps track of the system clock by counting timer interrupts.<br />
<br />
=== Read clock ===<br />
<br />
To check the current hardware clock time and system clock time respectively (the hardware clock time is presented in localtime even if the hardware clock set to UTC):<br />
<br />
$ timedatectl status<br />
<br />
=== Set clock ===<br />
<br />
To set the system clock directly:<br />
<br />
# timedatectl set-time "2012-10-30 18:17:16"<br />
<br />
=== RTC clock ===<br />
<br />
Standard behavior of most operating systems is:<br />
<br />
* Set the system clock from the hardware clock on boot<br />
* Keep accurate time of the system clock with an [[Network Time Protocol daemon|NTP]] daemon<br />
* Set the hardware clock from the system clock on shutdown.<br />
<br />
== Time standard ==<br />
<br />
There are two time standards: '''localtime''' and '''C'''oordinated '''U'''niversal '''T'''ime ('''UTC'''). The localtime standard is dependent on the current ''time zone'', while UTC is the ''global'' time standard and is independent of time zone values. Though conceptually different, UTC is also known as GMT (Greenwich Mean Time).<br />
<br />
The standard used by hardware clock (CMOS clock, the time that appears in BIOS) is defined by the operating system. By default, Windows uses localtime, Mac OS uses UTC, and UNIX-like operating systems vary. An OS that uses the UTC standard, generally, will consider CMOS (hardware clock) time a UTC time (GMT, Greenwich time) and make an adjustment to it while setting the System time on boot according to your time zone. <br />
<br />
When using Linux it is beneficial to have the hardware clock set to the UTC standard and made known to all operating systems. Defining the hardware clock in Linux as UTC means that Daylight Saving Time will automatically be accounted for. If using the localtime standard the system clock will not be changed for DST occurrences assuming that another operating system will take care of the DST switch (and provided no NTP agent is operating).<br />
<br />
You can set the hardware clock time standard through the command line. You can check what you have set your Arch Linux install to use by:<br />
<br />
$ timedatectl status | grep local<br />
<br />
The hardware clock can be queried and set with the {{ic|hwclock}} command. To change the hardware clock time standard to localtime use:<br />
<br />
# timedatectl set-local-rtc 1<br />
<br />
And to set it to UTC use:<br />
<br />
# timedatectl set-local-rtc 0<br />
<br />
These will generate {{ic|/etc/adjtime}} automatically; no further configuration is required.<br />
<br />
During kernel startup, at the point when the RTC driver is loaded, the system clock may be set from the hardware clock. Whether this occurs or not depends on the hardware platform, the version of the kernel and kernel build options. If this does occur, at this point in the boot sequence, the hardware clock time is assumed to be UTC and the value of {{ic|/proc/sys/class/rtcN/hctosys}} (N=0,1,2,..) will be set to 1. Later during execution of {{ic|/etc/rc.sysinit}}, the system clock is set again from the hardware clock dependent on the value of HARDWARECLOCK or from systemd dependent on values in {{ic|/etc/adjtime}}. Hence, having the hardware clock using localtime may cause some unexpected behavior during the boot sequence; e.g system time going backwards, which is always a bad idea.<br />
<br />
=== UTC in Windows ===<br />
<br />
Using {{ic|regedit}}, add a {{ic|DWORD}} value with hexadecimal value {{ic|1}} to the registry:<br />
<br />
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\TimeZoneInformation\RealTimeIsUniversal<br />
<br />
Alternatively, create a {{ic|*.reg}} file (on the desktop) with the following content and double click it to import it into registry:<br />
<br />
Windows Registry Editor Version 5.00<br />
<br />
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\TimeZoneInformation]<br />
"RealTimeIsUniversal"=dword:00000001<br />
<br />
Windows XP and Windows Vista SP1 have support for setting the time standard as UTC and can be activated in the same way. However, there is a bug after resuming from the suspend/hibernation state that resets the clock to ''localtime''. For these operating systems it is recommended to use ''localtime''.<br />
<br />
Should Windows ask to update the clock due to DST changes, let it. It will leave the clock in UTC as expected, only correcting the displayed time.<br />
<br />
The hardware clock and system clock time may need to be [[#Set clock|updated]] after setting this value.<br />
<br />
=== Common problems ===<br />
<br />
A common source of problems is that different programs that interact with the real time clock do not agree whether or not it should be in UTC or local time. This tends to manifest itself in the time being consistently off by the same number of hours as your time zone differs from UTC.<br />
<br />
This problem can usually be solved by only configuring the real time device in one location, by removing the HARDWARECLOCK line from {{ic|/etc/rc.conf}} and instead configuring this value in {{ic|/etc/adjtime}}. This is the default configuration location for the hwclock program, and initscripts will use this value if HARDWARECLOCK is not set in rc.conf.<br />
<br />
Once this is configured correctly, make sure that both system time and the real time clock are up-to-date before the next reboot.<br />
<br />
== Time Zone ==<br />
<br />
To check the current zone:<br />
<br />
$ timedatectl status<br />
<br />
To list available zones:<br />
<br />
$ timedatectl list-timezones<br />
<br />
To change your time zone:<br />
<br />
# timedatectl set-timezone <Zone>/<SubZone><br />
<br />
Example:<br />
<br />
# timedatectl set-timezone Canada/Eastern<br />
<br />
== Time Skew ==<br />
<br />
Every clock has a value that differs from ''real time'' (the best representation of which being [[Wikipedia:International Atomic Time|International Atomic Time]]); no clock is perfect. A quartz-based electronic clock keeps imperfect time, but maintains a consistent inaccuracy. This base 'inaccuracy' is known as 'time skew' or 'time drift'. <br />
<br />
When the hardware clock is set with {{ic|hwclock}}, a new drift value is calculated in seconds per day. The drift value is calculated by using the difference between the new value set and the hardware clock value just before the set, taking into account the value of the previous drift value and the last time the hardware clock was set. The new drift value and the time when the clock was set is written to the file {{ic|/etc/adjtime}} overwriting the previous values. The hardware clock can therefore be adjusted for drift when the command {{ic|hwclock --adjust}} is run; this also occurs on shutdown but only if the {{ic|hwclock}} daemon is enabled (hence for systems using systemd, this does not happen). <br />
<br />
{{Note|If the hwclock has been set again less than 24 hours after a previous set, the drift is not recalculated as {{ic|hwclock}} considers the elapsed time period too short to accurately calculate the drift.}}<br />
<br />
If the hardware clock keeps losing or gaining time in large increments, it is possible that an invalid drift has been recorded (but only applicable, if the hwclock daemon is running). This can happen if you have set the hardware clock time incorrectly or your [[#Time Standard|time standard]] is not synchronized with a Windows or Mac OS install. The drift value can be removed by removing the file {{ic|/etc/adjtime}}, then set the correct hardware clock and system clock time, and check if your [[#Time Standard|time standard]] is correct.<br />
<br />
{{Note|For those using systemd, but wish to make use of the drift value stored in {{ic|/etc/adjtime}} (i.e. perhaps cannot or dont want to use NTP); they need to call {{ic|hwclock --adjust}} on a regularly basis, perhaps by creating a cron job.}}<br />
<br />
The software clock is very accurate but like most clocks is not perfectly accurate and will drift as well. Though rarely, the system clock can lose accuracy if the kernel skips interrupts. There are some tools to improve software clock accuracy:<br />
* [[NTP]] can synchronize the software clock of a GNU/Linux system with internet time servers using the Network Time Protocol. NTP can also adjust the interrupt frequency and the number of ticks per second to decrease system clock drift. Running NTP will also cause the hardware clock to be re-synchronised every 11 minutes.<br />
* {{AUR|adjtimex}} in [[Arch User Repository|AUR]] can adjust kernel time variables like interrupt frequency to help improve the system clock time drift.<br />
<br />
== Resources ==<br />
<br />
* [http://www.linuxsa.org.au/tips/time.html Linux Tips - Linux, Clocks, and Time]<br />
* [http://www.twinsun.com/tz/tz-link.htm Sources for Time Zone and Daylight Saving Time Data] for {{Pkg|tzdata}}<br />
* [http://www.ucolick.org/~sla/leapsecs/timescales.html Time Scales]<br />
* [[Wikipedia:Time]]</div>PeterLhttps://wiki.archlinux.org/index.php?title=System_time&diff=233741System time2012-11-04T22:09:08Z<p>PeterL: /* Time Skew */</p>
<hr />
<div>[[es:TIMEZONE]]<br />
[[fa:زمان]]<br />
[[fr:Horloge]]<br />
[[ru:Time]]<br />
[[zh-CN:Time]]<br />
[[Category:Mainboards and BIOS]] <!-- with regard to the hardware clock --><br />
[[Category:Daemons and system services]] <!-- as the basis/rationale for NTP --><br />
{{Article summary start}}<br />
{{Article summary text|This article provides an introduction to the concept of keeping time on computers in general, and describes how clocks are configured and managed in Arch Linux.}}<br />
{{Article summary heading|Related}}<br />
{{Article summary wiki|Network Time Protocol}}<br />
{{Article summary end}}<br />
<br />
In an operating system the time (clock) is determined by four parts: Time value, Time standard, Time Zone, and DST ('''D'''aylight '''S'''aving '''T'''ime if applicable). This article explains what they are and how to read/set them. To ''maintain'' accurate system time on a network see [[Network Time Protocol]].<br />
<br />
== Hardware clock and system clock ==<br />
<br />
A computer has two clocks that need to be considered: the "Hardware clock" and the "System/software clock". <br />
<br />
'''Hardware clock''' (a.k.a. the Real Time Clock (RTC) or CMOS clock) stores the values of: Year, Month, Day, Hour, Minute, and the Seconds. It does not have the ability to store the time standard (localtime or UTC), nor whether DST is used. <br />
<br />
'''System clock''' (a.k.a. the software clock) keeps track of: Time, Time Zone, and DST if applicable. It is calculated by the Linux kernel as the number of seconds since midnight January 1st 1970, UTC. The initial value of the system clock is calculated from the hardware clock, dependent on the value of the HARDWARECLOCK variable defined in {{ic|/etc/rc.conf}} or for systems using systemd; the contents of {{ic|/etc/adjtime}}. After boot-up has completed the system clock runs independently of the hardware clock. The Linux kernel keeps track of the system clock by counting timer interrupts.<br />
<br />
=== Read clock ===<br />
<br />
To check the current hardware clock time and system clock time respectively (the hardware clock time is presented in localtime even if the hardware clock set to UTC):<br />
<br />
$ timedatectl status<br />
<br />
=== Set clock ===<br />
<br />
To set the system clock directly:<br />
<br />
# timedatectl set-time "2012-10-30 18:17:16"<br />
<br />
=== RTC clock ===<br />
<br />
Standard behavior of most operating systems is:<br />
<br />
* Set the system clock from the hardware clock on boot<br />
* Keep accurate time of the system clock with an [[Network Time Protocol daemon|NTP]] daemon<br />
* Set the hardware clock from the system clock on shutdown.<br />
<br />
== Time standard ==<br />
<br />
There are two time standards: '''localtime''' and '''C'''oordinated '''U'''niversal '''T'''ime ('''UTC'''). The localtime standard is dependent on the current ''time zone'', while UTC is the ''global'' time standard and is independent of time zone values. Though conceptually different, UTC is also known as GMT (Greenwich Mean Time).<br />
<br />
The standard used by hardware clock (CMOS clock, the time that appears in BIOS) is defined by the operating system. By default, Windows uses localtime, Mac OS uses UTC, and UNIX-like operating systems vary. An OS that uses the UTC standard, generally, will consider CMOS (hardware clock) time a UTC time (GMT, Greenwich time) and make an adjustment to it while setting the System time on boot according to your time zone. <br />
<br />
When using Linux it is beneficial to have the hardware clock set to the UTC standard and made known to all operating systems. Defining the hardware clock in Linux as UTC means that Daylight Saving Time will automatically be accounted for. If using the localtime standard the system clock will not be changed for DST occurrences assuming that another operating system will take care of the DST switch (and provided no NTP agent is operating).<br />
<br />
You can set the hardware clock time standard through the command line. You can check what you have set your Arch Linux install to use by:<br />
<br />
$ timedatectl status | grep local<br />
<br />
The hardware clock can be queried and set with the {{ic|hwclock}} command. To change the hardware clock time standard to localtime use:<br />
<br />
# timedatectl set-local-rtc 1<br />
<br />
And to set it to UTC use:<br />
<br />
# timedatectl set-local-rtc 0<br />
<br />
These will generate {{ic|/etc/adjtime}} automatically; no further configuration is required.<br />
<br />
During kernel startup, at the point when the RTC driver is loaded, the system clock may be set from the hardware clock. Whether this occurs or not depends on the hardware platform, the version of the kernel and kernel build options. If this does occur, at this point in the boot sequence, the hardware clock time is assumed to be UTC and the value of {{ic|/proc/sys/class/rtcN/hctosys}} (N=0,1,2,..) will be set to 1. Later during execution of {{ic|/etc/rc.sysinit}}, the system clock is set again from the hardware clock dependent on the value of HARDWARECLOCK or from systemd dependent on values in {{ic|/etc/adjtime}}. Hence, having the hardware clock using localtime may cause some unexpected behavior during the boot sequence; e.g system time going backwards, which is always a bad idea.<br />
<br />
=== UTC in Windows ===<br />
<br />
Using {{ic|regedit}}, add a {{ic|DWORD}} value with hexadecimal value {{ic|1}} to the registry:<br />
<br />
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\TimeZoneInformation\RealTimeIsUniversal<br />
<br />
Alternatively, create a {{ic|*.reg}} file (on the desktop) with the following content and double click it to import it into registry:<br />
<br />
Windows Registry Editor Version 5.00<br />
<br />
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\TimeZoneInformation]<br />
"RealTimeIsUniversal"=dword:00000001<br />
<br />
Windows XP and Windows Vista SP1 have support for setting the time standard as UTC and can be activated in the same way. However, there is a bug after resuming from the suspend/hibernation state that resets the clock to ''localtime''. For these operating systems it is recommended to use ''localtime''.<br />
<br />
Should Windows ask to update the clock due to DST changes, let it. It will leave the clock in UTC as expected, only correcting the displayed time.<br />
<br />
The hardware clock and system clock time may need to be [[#Set clock|updated]] after setting this value.<br />
<br />
=== Common problems ===<br />
<br />
A common source of problems is that different programs that interact with the real time clock do not agree whether or not it should be in UTC or local time. This tends to manifest itself in the time being consistently off by the same number of hours as your time zone differs from UTC.<br />
<br />
This problem can usually be solved by only configuring the real time device in one location, by removing the HARDWARECLOCK line from {{ic|/etc/rc.conf}} and instead configuring this value in {{ic|/etc/adjtime}}. This is the default configuration location for the hwclock program, and initscripts will use this value if HARDWARECLOCK is not set in rc.conf.<br />
<br />
Once this is configured correctly, make sure that both system time and the real time clock are up-to-date before the next reboot.<br />
<br />
== Time Zone ==<br />
<br />
To check the current zone:<br />
<br />
$ timedatectl status<br />
<br />
To list available zones:<br />
<br />
$ timedatectl list-timezones<br />
<br />
To change your time zone:<br />
<br />
# timedatectl set-timezone <Zone>/<SubZone><br />
<br />
Example:<br />
<br />
# timedatectl set-timezone Canada/Eastern<br />
<br />
== Time Skew ==<br />
<br />
Every clock has a value that differs from ''real time'' (the best representation of which being [[Wikipedia:International Atomic Time|International Atomic Time]]); no clock is perfect. A quartz-based electronic clock keeps imperfect time, but maintains a consistent inaccuracy. This base 'inaccuracy' is known as 'time skew' or 'time drift'. <br />
<br />
When the hardware clock is set with {{ic|hwclock}}, a new drift value is calculated in seconds per day. The drift value is calculated by using the difference between the new value set and the hardware clock value just before the set, taking into account the value of the previous drift value and the last time the hardware clock was set. The new drift value and the time when the clock was set is written to the file {{ic|/etc/adjtime}} overwriting the previous values. The hardware clock can therefore be adjusted for drift when the command {{ic|hwclock --adjust}} is run; this also occurs on shutdown but only if the {{ic|hwclock}} daemon is enabled (hence for systems using systemd, this does not happen). <br />
<br />
{{Note|If the hwclock has been set again less than 24 hours after a previous set, the drift is not recalculated as {{ic|hwclock}} considers the elapsed time period too short to accurately calculate the drift.}}<br />
<br />
If the hardware clock keeps losing or gaining time in large increments, it is possible that an invalid drift has been recorded (but only applicable, if the hwclock daemon is running). This can happen if you have set the hardware clock time incorrectly or your [[#Time Standard|time standard]] is not synchronized with a Windows or Mac OS install. The drift value can be removed by removing the file {{ic|/etc/adjtime}}, then set the correct hardware clock and system clock time, and check if your [[#Time Standard|time standard]] is correct.<br />
<br />
{{Note|For those using systemd, but wish to make use of the drift value stored in {{ic|/etc/adjtime}} (i.e. perhaps cannot or dont want to use NTP); they need to call {{ic|hwclock --adjust}} on a regularly basis, perhaps by creating a cron job.}}<br />
<br />
The software clock is very accurate but like most clocks is not perfectly accurate and will drift as well. Though rarely, the system clock can lose accuracy if the kernel skips interrupts. There are some tools to improve software clock accuracy:<br />
* [[NTP]] can synchronize the software clock of a GNU/Linux system with internet time servers using the Network Time Protocol. NTP can also adjust the interrupt frequency and the number of ticks per second to decrease system clock drift. Running NTP will also cause the hardware clock to be re-synchronised every 11 minutes.<br />
* {{AUR|adjtimex}} in [[Arch User Repository|AUR]] can adjust kernel time variables like interrupt frequency to help improve the system clock time drift.<br />
<br />
== Resources ==<br />
<br />
* [http://www.linuxsa.org.au/tips/time.html Linux Tips - Linux, Clocks, and Time]<br />
* [http://www.twinsun.com/tz/tz-link.htm Sources for Time Zone and Daylight Saving Time Data] for {{Pkg|tzdata}}<br />
* [http://www.ucolick.org/~sla/leapsecs/timescales.html Time Scales]<br />
* [[Wikipedia:Time]]</div>PeterLhttps://wiki.archlinux.org/index.php?title=System_time&diff=233740System time2012-11-04T22:08:34Z<p>PeterL: /* Time Skew */</p>
<hr />
<div>[[es:TIMEZONE]]<br />
[[fa:زمان]]<br />
[[fr:Horloge]]<br />
[[ru:Time]]<br />
[[zh-CN:Time]]<br />
[[Category:Mainboards and BIOS]] <!-- with regard to the hardware clock --><br />
[[Category:Daemons and system services]] <!-- as the basis/rationale for NTP --><br />
{{Article summary start}}<br />
{{Article summary text|This article provides an introduction to the concept of keeping time on computers in general, and describes how clocks are configured and managed in Arch Linux.}}<br />
{{Article summary heading|Related}}<br />
{{Article summary wiki|Network Time Protocol}}<br />
{{Article summary end}}<br />
<br />
In an operating system the time (clock) is determined by four parts: Time value, Time standard, Time Zone, and DST ('''D'''aylight '''S'''aving '''T'''ime if applicable). This article explains what they are and how to read/set them. To ''maintain'' accurate system time on a network see [[Network Time Protocol]].<br />
<br />
== Hardware clock and system clock ==<br />
<br />
A computer has two clocks that need to be considered: the "Hardware clock" and the "System/software clock". <br />
<br />
'''Hardware clock''' (a.k.a. the Real Time Clock (RTC) or CMOS clock) stores the values of: Year, Month, Day, Hour, Minute, and the Seconds. It does not have the ability to store the time standard (localtime or UTC), nor whether DST is used. <br />
<br />
'''System clock''' (a.k.a. the software clock) keeps track of: Time, Time Zone, and DST if applicable. It is calculated by the Linux kernel as the number of seconds since midnight January 1st 1970, UTC. The initial value of the system clock is calculated from the hardware clock, dependent on the value of the HARDWARECLOCK variable defined in {{ic|/etc/rc.conf}} or for systems using systemd; the contents of {{ic|/etc/adjtime}}. After boot-up has completed the system clock runs independently of the hardware clock. The Linux kernel keeps track of the system clock by counting timer interrupts.<br />
<br />
=== Read clock ===<br />
<br />
To check the current hardware clock time and system clock time respectively (the hardware clock time is presented in localtime even if the hardware clock set to UTC):<br />
<br />
$ timedatectl status<br />
<br />
=== Set clock ===<br />
<br />
To set the system clock directly:<br />
<br />
# timedatectl set-time "2012-10-30 18:17:16"<br />
<br />
=== RTC clock ===<br />
<br />
Standard behavior of most operating systems is:<br />
<br />
* Set the system clock from the hardware clock on boot<br />
* Keep accurate time of the system clock with an [[Network Time Protocol daemon|NTP]] daemon<br />
* Set the hardware clock from the system clock on shutdown.<br />
<br />
== Time standard ==<br />
<br />
There are two time standards: '''localtime''' and '''C'''oordinated '''U'''niversal '''T'''ime ('''UTC'''). The localtime standard is dependent on the current ''time zone'', while UTC is the ''global'' time standard and is independent of time zone values. Though conceptually different, UTC is also known as GMT (Greenwich Mean Time).<br />
<br />
The standard used by hardware clock (CMOS clock, the time that appears in BIOS) is defined by the operating system. By default, Windows uses localtime, Mac OS uses UTC, and UNIX-like operating systems vary. An OS that uses the UTC standard, generally, will consider CMOS (hardware clock) time a UTC time (GMT, Greenwich time) and make an adjustment to it while setting the System time on boot according to your time zone. <br />
<br />
When using Linux it is beneficial to have the hardware clock set to the UTC standard and made known to all operating systems. Defining the hardware clock in Linux as UTC means that Daylight Saving Time will automatically be accounted for. If using the localtime standard the system clock will not be changed for DST occurrences assuming that another operating system will take care of the DST switch (and provided no NTP agent is operating).<br />
<br />
You can set the hardware clock time standard through the command line. You can check what you have set your Arch Linux install to use by:<br />
<br />
$ timedatectl status | grep local<br />
<br />
The hardware clock can be queried and set with the {{ic|hwclock}} command. To change the hardware clock time standard to localtime use:<br />
<br />
# timedatectl set-local-rtc 1<br />
<br />
And to set it to UTC use:<br />
<br />
# timedatectl set-local-rtc 0<br />
<br />
These will generate {{ic|/etc/adjtime}} automatically; no further configuration is required.<br />
<br />
During kernel startup, at the point when the RTC driver is loaded, the system clock may be set from the hardware clock. Whether this occurs or not depends on the hardware platform, the version of the kernel and kernel build options. If this does occur, at this point in the boot sequence, the hardware clock time is assumed to be UTC and the value of {{ic|/proc/sys/class/rtcN/hctosys}} (N=0,1,2,..) will be set to 1. Later during execution of {{ic|/etc/rc.sysinit}}, the system clock is set again from the hardware clock dependent on the value of HARDWARECLOCK or from systemd dependent on values in {{ic|/etc/adjtime}}. Hence, having the hardware clock using localtime may cause some unexpected behavior during the boot sequence; e.g system time going backwards, which is always a bad idea.<br />
<br />
=== UTC in Windows ===<br />
<br />
Using {{ic|regedit}}, add a {{ic|DWORD}} value with hexadecimal value {{ic|1}} to the registry:<br />
<br />
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\TimeZoneInformation\RealTimeIsUniversal<br />
<br />
Alternatively, create a {{ic|*.reg}} file (on the desktop) with the following content and double click it to import it into registry:<br />
<br />
Windows Registry Editor Version 5.00<br />
<br />
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\TimeZoneInformation]<br />
"RealTimeIsUniversal"=dword:00000001<br />
<br />
Windows XP and Windows Vista SP1 have support for setting the time standard as UTC and can be activated in the same way. However, there is a bug after resuming from the suspend/hibernation state that resets the clock to ''localtime''. For these operating systems it is recommended to use ''localtime''.<br />
<br />
Should Windows ask to update the clock due to DST changes, let it. It will leave the clock in UTC as expected, only correcting the displayed time.<br />
<br />
The hardware clock and system clock time may need to be [[#Set clock|updated]] after setting this value.<br />
<br />
=== Common problems ===<br />
<br />
A common source of problems is that different programs that interact with the real time clock do not agree whether or not it should be in UTC or local time. This tends to manifest itself in the time being consistently off by the same number of hours as your time zone differs from UTC.<br />
<br />
This problem can usually be solved by only configuring the real time device in one location, by removing the HARDWARECLOCK line from {{ic|/etc/rc.conf}} and instead configuring this value in {{ic|/etc/adjtime}}. This is the default configuration location for the hwclock program, and initscripts will use this value if HARDWARECLOCK is not set in rc.conf.<br />
<br />
Once this is configured correctly, make sure that both system time and the real time clock are up-to-date before the next reboot.<br />
<br />
== Time Zone ==<br />
<br />
To check the current zone:<br />
<br />
$ timedatectl status<br />
<br />
To list available zones:<br />
<br />
$ timedatectl list-timezones<br />
<br />
To change your time zone:<br />
<br />
# timedatectl set-timezone <Zone>/<SubZone><br />
<br />
Example:<br />
<br />
# timedatectl set-timezone Canada/Eastern<br />
<br />
== Time Skew ==<br />
<br />
Every clock has a value that differs from ''real time'' (the best representation of which being [[Wikipedia:International Atomic Time|International Atomic Time]]); no clock is perfect. A quartz-based electronic clock keeps imperfect time, but maintains a consistent inaccuracy. This base 'inaccuracy' is known as 'time skew' or 'time drift'. <br />
<br />
When the hardware clock is set with {{ic|hwclock}}, a new drift value is calculated in seconds per day. The drift value is calculated by using the difference between the new value set and the hardware clock value just before the set, taking into account the value of the previous drift value and the last time the hardware clock was set. The new drift value and the time when the clock was set is written to the file {{ic|/etc/adjtime}} overwriting the previous values. The hardware clock can therefore be adjusted for drift when the command {{ic|hwclock --adjust}} is run; this also occurs on shutdown but only if the {{ic|hwclock}} daemon is enabled (hence for systems using systemd, this does not happen). <br />
<br />
{{Note|If the hwclock has been set again less than 24 hours after a previous set, the drift is not recalculated as {{ic|hwclock}} considers the elapsed time period too short to accurately calculate the drift.}}<br />
<br />
If the hardware clock keeps losing or gaining time in large increments, it is possible that an invalid drift has been recorded (but only applicable, if the hwclock daemon is running). This can happen if you have set the hardware clock time incorrectly or your [[#Time Standard|time standard]] is not synchronized with a Windows or Mac OS install. The drift value can be removed by removing the file {{ic|/etc/adjtime}}, then set the correct hardware clock and system clock time, and check if your [[#Time Standard|time standard]] is correct.<br />
<br />
{{Note|For those using systemd, but wish to may use of the drift value stored in {{ic|/etc/adjtime}} (i.e. perhaps cannot or dont want to use NTP); they need to call {{ic|hwclock --adjust}} on a regularly basis, perhaps by creating a cron job.}}<br />
<br />
The software clock is very accurate but like most clocks is not perfectly accurate and will drift as well. Though rarely, the system clock can lose accuracy if the kernel skips interrupts. There are some tools to improve software clock accuracy:<br />
* [[NTP]] can synchronize the software clock of a GNU/Linux system with internet time servers using the Network Time Protocol. NTP can also adjust the interrupt frequency and the number of ticks per second to decrease system clock drift. Running NTP will also cause the hardware clock to be re-synchronised every 11 minutes.<br />
* {{AUR|adjtimex}} in [[Arch User Repository|AUR]] can adjust kernel time variables like interrupt frequency to help improve the system clock time drift.<br />
<br />
== Resources ==<br />
<br />
* [http://www.linuxsa.org.au/tips/time.html Linux Tips - Linux, Clocks, and Time]<br />
* [http://www.twinsun.com/tz/tz-link.htm Sources for Time Zone and Daylight Saving Time Data] for {{Pkg|tzdata}}<br />
* [http://www.ucolick.org/~sla/leapsecs/timescales.html Time Scales]<br />
* [[Wikipedia:Time]]</div>PeterLhttps://wiki.archlinux.org/index.php?title=System_time&diff=233738System time2012-11-04T22:06:33Z<p>PeterL: /* Time Skew */</p>
<hr />
<div>[[es:TIMEZONE]]<br />
[[fa:زمان]]<br />
[[fr:Horloge]]<br />
[[ru:Time]]<br />
[[zh-CN:Time]]<br />
[[Category:Mainboards and BIOS]] <!-- with regard to the hardware clock --><br />
[[Category:Daemons and system services]] <!-- as the basis/rationale for NTP --><br />
{{Article summary start}}<br />
{{Article summary text|This article provides an introduction to the concept of keeping time on computers in general, and describes how clocks are configured and managed in Arch Linux.}}<br />
{{Article summary heading|Related}}<br />
{{Article summary wiki|Network Time Protocol}}<br />
{{Article summary end}}<br />
<br />
In an operating system the time (clock) is determined by four parts: Time value, Time standard, Time Zone, and DST ('''D'''aylight '''S'''aving '''T'''ime if applicable). This article explains what they are and how to read/set them. To ''maintain'' accurate system time on a network see [[Network Time Protocol]].<br />
<br />
== Hardware clock and system clock ==<br />
<br />
A computer has two clocks that need to be considered: the "Hardware clock" and the "System/software clock". <br />
<br />
'''Hardware clock''' (a.k.a. the Real Time Clock (RTC) or CMOS clock) stores the values of: Year, Month, Day, Hour, Minute, and the Seconds. It does not have the ability to store the time standard (localtime or UTC), nor whether DST is used. <br />
<br />
'''System clock''' (a.k.a. the software clock) keeps track of: Time, Time Zone, and DST if applicable. It is calculated by the Linux kernel as the number of seconds since midnight January 1st 1970, UTC. The initial value of the system clock is calculated from the hardware clock, dependent on the value of the HARDWARECLOCK variable defined in {{ic|/etc/rc.conf}} or for systems using systemd; the contents of {{ic|/etc/adjtime}}. After boot-up has completed the system clock runs independently of the hardware clock. The Linux kernel keeps track of the system clock by counting timer interrupts.<br />
<br />
=== Read clock ===<br />
<br />
To check the current hardware clock time and system clock time respectively (the hardware clock time is presented in localtime even if the hardware clock set to UTC):<br />
<br />
$ timedatectl status<br />
<br />
=== Set clock ===<br />
<br />
To set the system clock directly:<br />
<br />
# timedatectl set-time "2012-10-30 18:17:16"<br />
<br />
=== RTC clock ===<br />
<br />
Standard behavior of most operating systems is:<br />
<br />
* Set the system clock from the hardware clock on boot<br />
* Keep accurate time of the system clock with an [[Network Time Protocol daemon|NTP]] daemon<br />
* Set the hardware clock from the system clock on shutdown.<br />
<br />
== Time standard ==<br />
<br />
There are two time standards: '''localtime''' and '''C'''oordinated '''U'''niversal '''T'''ime ('''UTC'''). The localtime standard is dependent on the current ''time zone'', while UTC is the ''global'' time standard and is independent of time zone values. Though conceptually different, UTC is also known as GMT (Greenwich Mean Time).<br />
<br />
The standard used by hardware clock (CMOS clock, the time that appears in BIOS) is defined by the operating system. By default, Windows uses localtime, Mac OS uses UTC, and UNIX-like operating systems vary. An OS that uses the UTC standard, generally, will consider CMOS (hardware clock) time a UTC time (GMT, Greenwich time) and make an adjustment to it while setting the System time on boot according to your time zone. <br />
<br />
When using Linux it is beneficial to have the hardware clock set to the UTC standard and made known to all operating systems. Defining the hardware clock in Linux as UTC means that Daylight Saving Time will automatically be accounted for. If using the localtime standard the system clock will not be changed for DST occurrences assuming that another operating system will take care of the DST switch (and provided no NTP agent is operating).<br />
<br />
You can set the hardware clock time standard through the command line. You can check what you have set your Arch Linux install to use by:<br />
<br />
$ timedatectl status | grep local<br />
<br />
The hardware clock can be queried and set with the {{ic|hwclock}} command. To change the hardware clock time standard to localtime use:<br />
<br />
# timedatectl set-local-rtc 1<br />
<br />
And to set it to UTC use:<br />
<br />
# timedatectl set-local-rtc 0<br />
<br />
These will generate {{ic|/etc/adjtime}} automatically; no further configuration is required.<br />
<br />
During kernel startup, at the point when the RTC driver is loaded, the system clock may be set from the hardware clock. Whether this occurs or not depends on the hardware platform, the version of the kernel and kernel build options. If this does occur, at this point in the boot sequence, the hardware clock time is assumed to be UTC and the value of {{ic|/proc/sys/class/rtcN/hctosys}} (N=0,1,2,..) will be set to 1. Later during execution of {{ic|/etc/rc.sysinit}}, the system clock is set again from the hardware clock dependent on the value of HARDWARECLOCK or from systemd dependent on values in {{ic|/etc/adjtime}}. Hence, having the hardware clock using localtime may cause some unexpected behavior during the boot sequence; e.g system time going backwards, which is always a bad idea.<br />
<br />
=== UTC in Windows ===<br />
<br />
Using {{ic|regedit}}, add a {{ic|DWORD}} value with hexadecimal value {{ic|1}} to the registry:<br />
<br />
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\TimeZoneInformation\RealTimeIsUniversal<br />
<br />
Alternatively, create a {{ic|*.reg}} file (on the desktop) with the following content and double click it to import it into registry:<br />
<br />
Windows Registry Editor Version 5.00<br />
<br />
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\TimeZoneInformation]<br />
"RealTimeIsUniversal"=dword:00000001<br />
<br />
Windows XP and Windows Vista SP1 have support for setting the time standard as UTC and can be activated in the same way. However, there is a bug after resuming from the suspend/hibernation state that resets the clock to ''localtime''. For these operating systems it is recommended to use ''localtime''.<br />
<br />
Should Windows ask to update the clock due to DST changes, let it. It will leave the clock in UTC as expected, only correcting the displayed time.<br />
<br />
The hardware clock and system clock time may need to be [[#Set clock|updated]] after setting this value.<br />
<br />
=== Common problems ===<br />
<br />
A common source of problems is that different programs that interact with the real time clock do not agree whether or not it should be in UTC or local time. This tends to manifest itself in the time being consistently off by the same number of hours as your time zone differs from UTC.<br />
<br />
This problem can usually be solved by only configuring the real time device in one location, by removing the HARDWARECLOCK line from {{ic|/etc/rc.conf}} and instead configuring this value in {{ic|/etc/adjtime}}. This is the default configuration location for the hwclock program, and initscripts will use this value if HARDWARECLOCK is not set in rc.conf.<br />
<br />
Once this is configured correctly, make sure that both system time and the real time clock are up-to-date before the next reboot.<br />
<br />
== Time Zone ==<br />
<br />
To check the current zone:<br />
<br />
$ timedatectl status<br />
<br />
To list available zones:<br />
<br />
$ timedatectl list-timezones<br />
<br />
To change your time zone:<br />
<br />
# timedatectl set-timezone <Zone>/<SubZone><br />
<br />
Example:<br />
<br />
# timedatectl set-timezone Canada/Eastern<br />
<br />
== Time Skew ==<br />
<br />
Every clock has a value that differs from ''real time'' (the best representation of which being [[Wikipedia:International Atomic Time|International Atomic Time]]); no clock is perfect. A quartz-based electronic clock keeps imperfect time, but maintains a consistent inaccuracy. This base 'inaccuracy' is known as 'time skew' or 'time drift'. <br />
<br />
When the hardware clock is set with {{ic|hwclock}}, a new drift value is calculated in seconds per day. The drift value is calculated by using the difference between the new value set and the hardware clock value just before the set, taking into account the value of the previous drift value and the last time the hardware clock was set. The new drift value and the time when the clock was set is written to the file {{ic|/etc/adjtime}} overwriting the previous values. The hardware clock can therefore be adjusted for drift when the command {{ic|hwclock --adjust}} is run; this occurs by on shutdown only if the {{ic|hwclock}} daemon is enabled (for systems using systemd, this does not happen). <br />
<br />
{{Note|If the hwclock has been set again less than 24 hours after a previous set, the drift is not recalculated as {{ic|hwclock}} considers the elapsed time period too short to accurately calculate the drift.}}<br />
<br />
If the hardware clock keeps losing or gaining time in large increments, it is possible that an invalid drift has been recorded (but only applicable, if the hwclock daemon is running). This can happen if you have set the hardware clock time incorrectly or your [[#Time Standard|time standard]] is not synchronized with a Windows or Mac OS install. The drift value can be removed by removing the file {{ic|/etc/adjtime}}, then set the correct hardware clock and system clock time, and check if your [[#Time Standard|time standard]] is correct.<br />
<br />
{{Note|For those using systemd, but wish to may use of the drift value stored in {{ic|/etc/adjtime}} (i.e. perhaps cannot or dont want to use NTP); they need to call {{ic|hwclock --adjust}} on a regularly basis, perhaps by creating a cron job.}}<br />
<br />
The software clock is very accurate but like most clocks is not perfectly accurate and will drift as well. Though rarely, the system clock can lose accuracy if the kernel skips interrupts. There are some tools to improve software clock accuracy:<br />
* [[NTP]] can synchronize the software clock of a GNU/Linux system with internet time servers using the Network Time Protocol. NTP can also adjust the interrupt frequency and the number of ticks per second to decrease system clock drift. Running NTP will also cause the hardware clock to be re-synchronised every 11 minutes.<br />
* {{AUR|adjtimex}} in [[Arch User Repository|AUR]] can adjust kernel time variables like interrupt frequency to help improve the system clock time drift.<br />
<br />
== Resources ==<br />
<br />
* [http://www.linuxsa.org.au/tips/time.html Linux Tips - Linux, Clocks, and Time]<br />
* [http://www.twinsun.com/tz/tz-link.htm Sources for Time Zone and Daylight Saving Time Data] for {{Pkg|tzdata}}<br />
* [http://www.ucolick.org/~sla/leapsecs/timescales.html Time Scales]<br />
* [[Wikipedia:Time]]</div>PeterLhttps://wiki.archlinux.org/index.php?title=System_time&diff=233737System time2012-11-04T22:05:03Z<p>PeterL: /* Time Skew */</p>
<hr />
<div>[[es:TIMEZONE]]<br />
[[fa:زمان]]<br />
[[fr:Horloge]]<br />
[[ru:Time]]<br />
[[zh-CN:Time]]<br />
[[Category:Mainboards and BIOS]] <!-- with regard to the hardware clock --><br />
[[Category:Daemons and system services]] <!-- as the basis/rationale for NTP --><br />
{{Article summary start}}<br />
{{Article summary text|This article provides an introduction to the concept of keeping time on computers in general, and describes how clocks are configured and managed in Arch Linux.}}<br />
{{Article summary heading|Related}}<br />
{{Article summary wiki|Network Time Protocol}}<br />
{{Article summary end}}<br />
<br />
In an operating system the time (clock) is determined by four parts: Time value, Time standard, Time Zone, and DST ('''D'''aylight '''S'''aving '''T'''ime if applicable). This article explains what they are and how to read/set them. To ''maintain'' accurate system time on a network see [[Network Time Protocol]].<br />
<br />
== Hardware clock and system clock ==<br />
<br />
A computer has two clocks that need to be considered: the "Hardware clock" and the "System/software clock". <br />
<br />
'''Hardware clock''' (a.k.a. the Real Time Clock (RTC) or CMOS clock) stores the values of: Year, Month, Day, Hour, Minute, and the Seconds. It does not have the ability to store the time standard (localtime or UTC), nor whether DST is used. <br />
<br />
'''System clock''' (a.k.a. the software clock) keeps track of: Time, Time Zone, and DST if applicable. It is calculated by the Linux kernel as the number of seconds since midnight January 1st 1970, UTC. The initial value of the system clock is calculated from the hardware clock, dependent on the value of the HARDWARECLOCK variable defined in {{ic|/etc/rc.conf}} or for systems using systemd; the contents of {{ic|/etc/adjtime}}. After boot-up has completed the system clock runs independently of the hardware clock. The Linux kernel keeps track of the system clock by counting timer interrupts.<br />
<br />
=== Read clock ===<br />
<br />
To check the current hardware clock time and system clock time respectively (the hardware clock time is presented in localtime even if the hardware clock set to UTC):<br />
<br />
$ timedatectl status<br />
<br />
=== Set clock ===<br />
<br />
To set the system clock directly:<br />
<br />
# timedatectl set-time "2012-10-30 18:17:16"<br />
<br />
=== RTC clock ===<br />
<br />
Standard behavior of most operating systems is:<br />
<br />
* Set the system clock from the hardware clock on boot<br />
* Keep accurate time of the system clock with an [[Network Time Protocol daemon|NTP]] daemon<br />
* Set the hardware clock from the system clock on shutdown.<br />
<br />
== Time standard ==<br />
<br />
There are two time standards: '''localtime''' and '''C'''oordinated '''U'''niversal '''T'''ime ('''UTC'''). The localtime standard is dependent on the current ''time zone'', while UTC is the ''global'' time standard and is independent of time zone values. Though conceptually different, UTC is also known as GMT (Greenwich Mean Time).<br />
<br />
The standard used by hardware clock (CMOS clock, the time that appears in BIOS) is defined by the operating system. By default, Windows uses localtime, Mac OS uses UTC, and UNIX-like operating systems vary. An OS that uses the UTC standard, generally, will consider CMOS (hardware clock) time a UTC time (GMT, Greenwich time) and make an adjustment to it while setting the System time on boot according to your time zone. <br />
<br />
When using Linux it is beneficial to have the hardware clock set to the UTC standard and made known to all operating systems. Defining the hardware clock in Linux as UTC means that Daylight Saving Time will automatically be accounted for. If using the localtime standard the system clock will not be changed for DST occurrences assuming that another operating system will take care of the DST switch (and provided no NTP agent is operating).<br />
<br />
You can set the hardware clock time standard through the command line. You can check what you have set your Arch Linux install to use by:<br />
<br />
$ timedatectl status | grep local<br />
<br />
The hardware clock can be queried and set with the {{ic|hwclock}} command. To change the hardware clock time standard to localtime use:<br />
<br />
# timedatectl set-local-rtc 1<br />
<br />
And to set it to UTC use:<br />
<br />
# timedatectl set-local-rtc 0<br />
<br />
These will generate {{ic|/etc/adjtime}} automatically; no further configuration is required.<br />
<br />
During kernel startup, at the point when the RTC driver is loaded, the system clock may be set from the hardware clock. Whether this occurs or not depends on the hardware platform, the version of the kernel and kernel build options. If this does occur, at this point in the boot sequence, the hardware clock time is assumed to be UTC and the value of {{ic|/proc/sys/class/rtcN/hctosys}} (N=0,1,2,..) will be set to 1. Later during execution of {{ic|/etc/rc.sysinit}}, the system clock is set again from the hardware clock dependent on the value of HARDWARECLOCK or from systemd dependent on values in {{ic|/etc/adjtime}}. Hence, having the hardware clock using localtime may cause some unexpected behavior during the boot sequence; e.g system time going backwards, which is always a bad idea.<br />
<br />
=== UTC in Windows ===<br />
<br />
Using {{ic|regedit}}, add a {{ic|DWORD}} value with hexadecimal value {{ic|1}} to the registry:<br />
<br />
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\TimeZoneInformation\RealTimeIsUniversal<br />
<br />
Alternatively, create a {{ic|*.reg}} file (on the desktop) with the following content and double click it to import it into registry:<br />
<br />
Windows Registry Editor Version 5.00<br />
<br />
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\TimeZoneInformation]<br />
"RealTimeIsUniversal"=dword:00000001<br />
<br />
Windows XP and Windows Vista SP1 have support for setting the time standard as UTC and can be activated in the same way. However, there is a bug after resuming from the suspend/hibernation state that resets the clock to ''localtime''. For these operating systems it is recommended to use ''localtime''.<br />
<br />
Should Windows ask to update the clock due to DST changes, let it. It will leave the clock in UTC as expected, only correcting the displayed time.<br />
<br />
The hardware clock and system clock time may need to be [[#Set clock|updated]] after setting this value.<br />
<br />
=== Common problems ===<br />
<br />
A common source of problems is that different programs that interact with the real time clock do not agree whether or not it should be in UTC or local time. This tends to manifest itself in the time being consistently off by the same number of hours as your time zone differs from UTC.<br />
<br />
This problem can usually be solved by only configuring the real time device in one location, by removing the HARDWARECLOCK line from {{ic|/etc/rc.conf}} and instead configuring this value in {{ic|/etc/adjtime}}. This is the default configuration location for the hwclock program, and initscripts will use this value if HARDWARECLOCK is not set in rc.conf.<br />
<br />
Once this is configured correctly, make sure that both system time and the real time clock are up-to-date before the next reboot.<br />
<br />
== Time Zone ==<br />
<br />
To check the current zone:<br />
<br />
$ timedatectl status<br />
<br />
To list available zones:<br />
<br />
$ timedatectl list-timezones<br />
<br />
To change your time zone:<br />
<br />
# timedatectl set-timezone <Zone>/<SubZone><br />
<br />
Example:<br />
<br />
# timedatectl set-timezone Canada/Eastern<br />
<br />
== Time Skew ==<br />
<br />
Every clock has a value that differs from ''real time'' (the best representation of which being [[Wikipedia:International Atomic Time|International Atomic Time]]); no clock is perfect. A quartz-based electronic clock keeps imperfect time, but maintains a consistent inaccuracy. This base 'inaccuracy' is known as 'time skew' or 'time drift'. <br />
<br />
When the hardware clock is set with {{ic|hwclock}}, a new drift value is calculated in seconds per day. The drift value is calculated by using the difference between the new value set and the hardware clock value just before the set, taking into account the value of the previous drift value and the last time the hardware clock was set. The new drift value and the time when the clock was set is written to the file {{ic|/etc/adjtime}} overwriting the previous values. The hardware clock can be adjusted for drift when the command {{ic|hwclock --adjust}} is run; this occurs by on shutdown only if the {{ic|hwclock}} daemon is enabled (for systems using systemd, this does not happen). <br />
<br />
{{Note|If the hwclock has been set again less than 24 hours after a previous set, the drift is not recalculated as {{ic|hwclock}} considers the elapsed time period too short to accurately calculate the drift.}}<br />
<br />
If the hardware clock keeps losing or gaining time in large increments, it is possible that an invalid drift has been recorded (but only applicable, if the hwclock daemon is running). This can happen if you have set the hardware clock time incorrectly or your [[#Time Standard|time standard]] is not synchronized with a Windows or Mac OS install. The drift value can be removed by removing the file {{ic|/etc/adjtime}}, then set the correct hardware clock and system clock time, and check if your [[#Time Standard|time standard]] is correct.<br />
<br />
{{Note|For those using systemd, but wish to may use of the drift value stored in {{ic|/etc/adjtime}} (i.e. perhaps cannot or dont want to use NTP); they need to call {{ic|hwclock --adjust}} on a regularly basis, perhaps by creating a cron job.}}<br />
<br />
The software clock is very accurate but like most clocks is not perfectly accurate and will drift as well. Though rarely, the system clock can lose accuracy if the kernel skips interrupts. There are some tools to improve software clock accuracy:<br />
* [[NTP]] can synchronize the software clock of a GNU/Linux system with internet time servers using the Network Time Protocol. NTP can also adjust the interrupt frequency and the number of ticks per second to decrease system clock drift. Running NTP will also cause the hardware clock to be re-synchronised every 11 minutes.<br />
* {{AUR|adjtimex}} in [[Arch User Repository|AUR]] can adjust kernel time variables like interrupt frequency to help improve the system clock time drift.<br />
<br />
== Resources ==<br />
<br />
* [http://www.linuxsa.org.au/tips/time.html Linux Tips - Linux, Clocks, and Time]<br />
* [http://www.twinsun.com/tz/tz-link.htm Sources for Time Zone and Daylight Saving Time Data] for {{Pkg|tzdata}}<br />
* [http://www.ucolick.org/~sla/leapsecs/timescales.html Time Scales]<br />
* [[Wikipedia:Time]]</div>PeterLhttps://wiki.archlinux.org/index.php?title=System_time&diff=233736System time2012-11-04T22:04:27Z<p>PeterL: /* Time Skew */</p>
<hr />
<div>[[es:TIMEZONE]]<br />
[[fa:زمان]]<br />
[[fr:Horloge]]<br />
[[ru:Time]]<br />
[[zh-CN:Time]]<br />
[[Category:Mainboards and BIOS]] <!-- with regard to the hardware clock --><br />
[[Category:Daemons and system services]] <!-- as the basis/rationale for NTP --><br />
{{Article summary start}}<br />
{{Article summary text|This article provides an introduction to the concept of keeping time on computers in general, and describes how clocks are configured and managed in Arch Linux.}}<br />
{{Article summary heading|Related}}<br />
{{Article summary wiki|Network Time Protocol}}<br />
{{Article summary end}}<br />
<br />
In an operating system the time (clock) is determined by four parts: Time value, Time standard, Time Zone, and DST ('''D'''aylight '''S'''aving '''T'''ime if applicable). This article explains what they are and how to read/set them. To ''maintain'' accurate system time on a network see [[Network Time Protocol]].<br />
<br />
== Hardware clock and system clock ==<br />
<br />
A computer has two clocks that need to be considered: the "Hardware clock" and the "System/software clock". <br />
<br />
'''Hardware clock''' (a.k.a. the Real Time Clock (RTC) or CMOS clock) stores the values of: Year, Month, Day, Hour, Minute, and the Seconds. It does not have the ability to store the time standard (localtime or UTC), nor whether DST is used. <br />
<br />
'''System clock''' (a.k.a. the software clock) keeps track of: Time, Time Zone, and DST if applicable. It is calculated by the Linux kernel as the number of seconds since midnight January 1st 1970, UTC. The initial value of the system clock is calculated from the hardware clock, dependent on the value of the HARDWARECLOCK variable defined in {{ic|/etc/rc.conf}} or for systems using systemd; the contents of {{ic|/etc/adjtime}}. After boot-up has completed the system clock runs independently of the hardware clock. The Linux kernel keeps track of the system clock by counting timer interrupts.<br />
<br />
=== Read clock ===<br />
<br />
To check the current hardware clock time and system clock time respectively (the hardware clock time is presented in localtime even if the hardware clock set to UTC):<br />
<br />
$ timedatectl status<br />
<br />
=== Set clock ===<br />
<br />
To set the system clock directly:<br />
<br />
# timedatectl set-time "2012-10-30 18:17:16"<br />
<br />
=== RTC clock ===<br />
<br />
Standard behavior of most operating systems is:<br />
<br />
* Set the system clock from the hardware clock on boot<br />
* Keep accurate time of the system clock with an [[Network Time Protocol daemon|NTP]] daemon<br />
* Set the hardware clock from the system clock on shutdown.<br />
<br />
== Time standard ==<br />
<br />
There are two time standards: '''localtime''' and '''C'''oordinated '''U'''niversal '''T'''ime ('''UTC'''). The localtime standard is dependent on the current ''time zone'', while UTC is the ''global'' time standard and is independent of time zone values. Though conceptually different, UTC is also known as GMT (Greenwich Mean Time).<br />
<br />
The standard used by hardware clock (CMOS clock, the time that appears in BIOS) is defined by the operating system. By default, Windows uses localtime, Mac OS uses UTC, and UNIX-like operating systems vary. An OS that uses the UTC standard, generally, will consider CMOS (hardware clock) time a UTC time (GMT, Greenwich time) and make an adjustment to it while setting the System time on boot according to your time zone. <br />
<br />
When using Linux it is beneficial to have the hardware clock set to the UTC standard and made known to all operating systems. Defining the hardware clock in Linux as UTC means that Daylight Saving Time will automatically be accounted for. If using the localtime standard the system clock will not be changed for DST occurrences assuming that another operating system will take care of the DST switch (and provided no NTP agent is operating).<br />
<br />
You can set the hardware clock time standard through the command line. You can check what you have set your Arch Linux install to use by:<br />
<br />
$ timedatectl status | grep local<br />
<br />
The hardware clock can be queried and set with the {{ic|hwclock}} command. To change the hardware clock time standard to localtime use:<br />
<br />
# timedatectl set-local-rtc 1<br />
<br />
And to set it to UTC use:<br />
<br />
# timedatectl set-local-rtc 0<br />
<br />
These will generate {{ic|/etc/adjtime}} automatically; no further configuration is required.<br />
<br />
During kernel startup, at the point when the RTC driver is loaded, the system clock may be set from the hardware clock. Whether this occurs or not depends on the hardware platform, the version of the kernel and kernel build options. If this does occur, at this point in the boot sequence, the hardware clock time is assumed to be UTC and the value of {{ic|/proc/sys/class/rtcN/hctosys}} (N=0,1,2,..) will be set to 1. Later during execution of {{ic|/etc/rc.sysinit}}, the system clock is set again from the hardware clock dependent on the value of HARDWARECLOCK or from systemd dependent on values in {{ic|/etc/adjtime}}. Hence, having the hardware clock using localtime may cause some unexpected behavior during the boot sequence; e.g system time going backwards, which is always a bad idea.<br />
<br />
=== UTC in Windows ===<br />
<br />
Using {{ic|regedit}}, add a {{ic|DWORD}} value with hexadecimal value {{ic|1}} to the registry:<br />
<br />
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\TimeZoneInformation\RealTimeIsUniversal<br />
<br />
Alternatively, create a {{ic|*.reg}} file (on the desktop) with the following content and double click it to import it into registry:<br />
<br />
Windows Registry Editor Version 5.00<br />
<br />
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\TimeZoneInformation]<br />
"RealTimeIsUniversal"=dword:00000001<br />
<br />
Windows XP and Windows Vista SP1 have support for setting the time standard as UTC and can be activated in the same way. However, there is a bug after resuming from the suspend/hibernation state that resets the clock to ''localtime''. For these operating systems it is recommended to use ''localtime''.<br />
<br />
Should Windows ask to update the clock due to DST changes, let it. It will leave the clock in UTC as expected, only correcting the displayed time.<br />
<br />
The hardware clock and system clock time may need to be [[#Set clock|updated]] after setting this value.<br />
<br />
=== Common problems ===<br />
<br />
A common source of problems is that different programs that interact with the real time clock do not agree whether or not it should be in UTC or local time. This tends to manifest itself in the time being consistently off by the same number of hours as your time zone differs from UTC.<br />
<br />
This problem can usually be solved by only configuring the real time device in one location, by removing the HARDWARECLOCK line from {{ic|/etc/rc.conf}} and instead configuring this value in {{ic|/etc/adjtime}}. This is the default configuration location for the hwclock program, and initscripts will use this value if HARDWARECLOCK is not set in rc.conf.<br />
<br />
Once this is configured correctly, make sure that both system time and the real time clock are up-to-date before the next reboot.<br />
<br />
== Time Zone ==<br />
<br />
To check the current zone:<br />
<br />
$ timedatectl status<br />
<br />
To list available zones:<br />
<br />
$ timedatectl list-timezones<br />
<br />
To change your time zone:<br />
<br />
# timedatectl set-timezone <Zone>/<SubZone><br />
<br />
Example:<br />
<br />
# timedatectl set-timezone Canada/Eastern<br />
<br />
== Time Skew ==<br />
<br />
Every clock has a value that differs from ''real time'' (the best representation of which being [[Wikipedia:International Atomic Time|International Atomic Time]]); no clock is perfect. A quartz-based electronic clock keeps imperfect time, but maintains a consistent inaccuracy. This base 'inaccuracy' is known as 'time skew' or 'time drift'. <br />
<br />
When the hardware clock is set with {{ic|hwclock}}, a new drift value is calculated in seconds per day. The drift value is calculated by using the difference between the new value set and the hardware clock value just before the set, taking into account the value of the previous drift value and the last time the hardware clock was set. The new drift value and the time when the clock was set is written to the file {{ic|/etc/adjtime}} overwriting the previous values. The hardware clock can be adjusted for drift when the command {{ic|hwclock --adjust}} is run; this occurs by on shutdown only if the {{ic|hwclock}} daemon is enabled (for systems using systemd, this does not happen). <br />
<br />
{{Note|If the hwclock has been set again less than 24 hours after a previous set, the drift is not recalculated as {{ic|hwclock}} considers the elapsed time period too short to accurately calculate the drift.}}<br />
<br />
If the hardware clock keeps losing or gaining time in large increments, it is possible that an invalid drift has been recorded (but only applicable, if the hwclock daemon is running). This can happen if you have set the hardware clock time incorrectly or your [[#Time Standard|time standard]] is not synchronized with a Windows or Mac OS install. The drift value can be removed by removing the file {{ic|/etc/adjtime}}, then set the correct hardware clock and system clock time, and check if your [[#Time Standard|time standard]] is correct.<br />
<br />
{{Note|For those using systemd, but wish to may use of the drift value stored in {{ic|/etc/adjtime}} (i.e. perhaps cannot or dont want to use NTP); they need to call {{ic|hwclock -- adjust}} on a regularly basis, perhaps by creating a cron job.}}<br />
<br />
The software clock is very accurate but like most clocks is not perfectly accurate and will drift as well. Though rarely, the system clock can lose accuracy if the kernel skips interrupts. There are some tools to improve software clock accuracy:<br />
* [[NTP]] can synchronize the software clock of a GNU/Linux system with internet time servers using the Network Time Protocol. NTP can also adjust the interrupt frequency and the number of ticks per second to decrease system clock drift. Running NTP will also cause the hardware clock to be re-synchronised every 11 minutes.<br />
* {{AUR|adjtimex}} in [[Arch User Repository|AUR]] can adjust kernel time variables like interrupt frequency to help improve the system clock time drift.<br />
<br />
== Resources ==<br />
<br />
* [http://www.linuxsa.org.au/tips/time.html Linux Tips - Linux, Clocks, and Time]<br />
* [http://www.twinsun.com/tz/tz-link.htm Sources for Time Zone and Daylight Saving Time Data] for {{Pkg|tzdata}}<br />
* [http://www.ucolick.org/~sla/leapsecs/timescales.html Time Scales]<br />
* [[Wikipedia:Time]]</div>PeterLhttps://wiki.archlinux.org/index.php?title=System_time&diff=233734System time2012-11-04T22:00:54Z<p>PeterL: /* Time Skew */</p>
<hr />
<div>[[es:TIMEZONE]]<br />
[[fa:زمان]]<br />
[[fr:Horloge]]<br />
[[ru:Time]]<br />
[[zh-CN:Time]]<br />
[[Category:Mainboards and BIOS]] <!-- with regard to the hardware clock --><br />
[[Category:Daemons and system services]] <!-- as the basis/rationale for NTP --><br />
{{Article summary start}}<br />
{{Article summary text|This article provides an introduction to the concept of keeping time on computers in general, and describes how clocks are configured and managed in Arch Linux.}}<br />
{{Article summary heading|Related}}<br />
{{Article summary wiki|Network Time Protocol}}<br />
{{Article summary end}}<br />
<br />
In an operating system the time (clock) is determined by four parts: Time value, Time standard, Time Zone, and DST ('''D'''aylight '''S'''aving '''T'''ime if applicable). This article explains what they are and how to read/set them. To ''maintain'' accurate system time on a network see [[Network Time Protocol]].<br />
<br />
== Hardware clock and system clock ==<br />
<br />
A computer has two clocks that need to be considered: the "Hardware clock" and the "System/software clock". <br />
<br />
'''Hardware clock''' (a.k.a. the Real Time Clock (RTC) or CMOS clock) stores the values of: Year, Month, Day, Hour, Minute, and the Seconds. It does not have the ability to store the time standard (localtime or UTC), nor whether DST is used. <br />
<br />
'''System clock''' (a.k.a. the software clock) keeps track of: Time, Time Zone, and DST if applicable. It is calculated by the Linux kernel as the number of seconds since midnight January 1st 1970, UTC. The initial value of the system clock is calculated from the hardware clock, dependent on the value of the HARDWARECLOCK variable defined in {{ic|/etc/rc.conf}} or for systems using systemd; the contents of {{ic|/etc/adjtime}}. After boot-up has completed the system clock runs independently of the hardware clock. The Linux kernel keeps track of the system clock by counting timer interrupts.<br />
<br />
=== Read clock ===<br />
<br />
To check the current hardware clock time and system clock time respectively (the hardware clock time is presented in localtime even if the hardware clock set to UTC):<br />
<br />
$ timedatectl status<br />
<br />
=== Set clock ===<br />
<br />
To set the system clock directly:<br />
<br />
# timedatectl set-time "2012-10-30 18:17:16"<br />
<br />
=== RTC clock ===<br />
<br />
Standard behavior of most operating systems is:<br />
<br />
* Set the system clock from the hardware clock on boot<br />
* Keep accurate time of the system clock with an [[Network Time Protocol daemon|NTP]] daemon<br />
* Set the hardware clock from the system clock on shutdown.<br />
<br />
== Time standard ==<br />
<br />
There are two time standards: '''localtime''' and '''C'''oordinated '''U'''niversal '''T'''ime ('''UTC'''). The localtime standard is dependent on the current ''time zone'', while UTC is the ''global'' time standard and is independent of time zone values. Though conceptually different, UTC is also known as GMT (Greenwich Mean Time).<br />
<br />
The standard used by hardware clock (CMOS clock, the time that appears in BIOS) is defined by the operating system. By default, Windows uses localtime, Mac OS uses UTC, and UNIX-like operating systems vary. An OS that uses the UTC standard, generally, will consider CMOS (hardware clock) time a UTC time (GMT, Greenwich time) and make an adjustment to it while setting the System time on boot according to your time zone. <br />
<br />
When using Linux it is beneficial to have the hardware clock set to the UTC standard and made known to all operating systems. Defining the hardware clock in Linux as UTC means that Daylight Saving Time will automatically be accounted for. If using the localtime standard the system clock will not be changed for DST occurrences assuming that another operating system will take care of the DST switch (and provided no NTP agent is operating).<br />
<br />
You can set the hardware clock time standard through the command line. You can check what you have set your Arch Linux install to use by:<br />
<br />
$ timedatectl status | grep local<br />
<br />
The hardware clock can be queried and set with the {{ic|hwclock}} command. To change the hardware clock time standard to localtime use:<br />
<br />
# timedatectl set-local-rtc 1<br />
<br />
And to set it to UTC use:<br />
<br />
# timedatectl set-local-rtc 0<br />
<br />
These will generate {{ic|/etc/adjtime}} automatically; no further configuration is required.<br />
<br />
During kernel startup, at the point when the RTC driver is loaded, the system clock may be set from the hardware clock. Whether this occurs or not depends on the hardware platform, the version of the kernel and kernel build options. If this does occur, at this point in the boot sequence, the hardware clock time is assumed to be UTC and the value of {{ic|/proc/sys/class/rtcN/hctosys}} (N=0,1,2,..) will be set to 1. Later during execution of {{ic|/etc/rc.sysinit}}, the system clock is set again from the hardware clock dependent on the value of HARDWARECLOCK or from systemd dependent on values in {{ic|/etc/adjtime}}. Hence, having the hardware clock using localtime may cause some unexpected behavior during the boot sequence; e.g system time going backwards, which is always a bad idea.<br />
<br />
=== UTC in Windows ===<br />
<br />
Using {{ic|regedit}}, add a {{ic|DWORD}} value with hexadecimal value {{ic|1}} to the registry:<br />
<br />
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\TimeZoneInformation\RealTimeIsUniversal<br />
<br />
Alternatively, create a {{ic|*.reg}} file (on the desktop) with the following content and double click it to import it into registry:<br />
<br />
Windows Registry Editor Version 5.00<br />
<br />
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\TimeZoneInformation]<br />
"RealTimeIsUniversal"=dword:00000001<br />
<br />
Windows XP and Windows Vista SP1 have support for setting the time standard as UTC and can be activated in the same way. However, there is a bug after resuming from the suspend/hibernation state that resets the clock to ''localtime''. For these operating systems it is recommended to use ''localtime''.<br />
<br />
Should Windows ask to update the clock due to DST changes, let it. It will leave the clock in UTC as expected, only correcting the displayed time.<br />
<br />
The hardware clock and system clock time may need to be [[#Set clock|updated]] after setting this value.<br />
<br />
=== Common problems ===<br />
<br />
A common source of problems is that different programs that interact with the real time clock do not agree whether or not it should be in UTC or local time. This tends to manifest itself in the time being consistently off by the same number of hours as your time zone differs from UTC.<br />
<br />
This problem can usually be solved by only configuring the real time device in one location, by removing the HARDWARECLOCK line from {{ic|/etc/rc.conf}} and instead configuring this value in {{ic|/etc/adjtime}}. This is the default configuration location for the hwclock program, and initscripts will use this value if HARDWARECLOCK is not set in rc.conf.<br />
<br />
Once this is configured correctly, make sure that both system time and the real time clock are up-to-date before the next reboot.<br />
<br />
== Time Zone ==<br />
<br />
To check the current zone:<br />
<br />
$ timedatectl status<br />
<br />
To list available zones:<br />
<br />
$ timedatectl list-timezones<br />
<br />
To change your time zone:<br />
<br />
# timedatectl set-timezone <Zone>/<SubZone><br />
<br />
Example:<br />
<br />
# timedatectl set-timezone Canada/Eastern<br />
<br />
== Time Skew ==<br />
<br />
Every clock has a value that differs from ''real time'' (the best representation of which being [[Wikipedia:International Atomic Time|International Atomic Time]]); no clock is perfect. A quartz-based electronic clock keeps imperfect time, but maintains a consistent inaccuracy. This base 'inaccuracy' is known as 'time skew' or 'time drift'. <br />
<br />
When the hardware clock is set with {{ic|hwclock}}, a new drift value is calculated in seconds per day. The drift value is calculated by using the difference between the new value set and the hardware clock value just before the set, taking into account the value of the previous drift value and the last time the hardware clock was set. The new drift value and the time when the clock was set is written to the file {{ic|/etc/adjtime}} overwriting the previous values. The hardware clock can be adjusted for drift when the command {{ic|hwclock --adjust}} is run; this occurs by on shutdown only if the {{ic|hwclock}} daemon is enabled (for systems using systemd, this does not happen). <br />
<br />
{{Note|If the hwclock has been set again less than 24 hours after a previous set, the drift is not recalculated as {{ic|hwclock}} considers the elapsed time period too short to accurately calculate the drift.}}<br />
<br />
If the hardware clock keeps losing or gaining time in large increments, it is possible that an invalid drift has been recorded (but only applicable, if the hwclock daemon is running). This can happen if you have set the hardware clock time incorrectly or your [[#Time Standard|time standard]] is not synchronized with a Windows or Mac OS install. The drift value can be removed by removing the file {{ic|/etc/adjtime}}, then set the correct hardware clock and system clock time, and check if your [[#Time Standard|time standard]] is correct.<br />
<br />
{{Note|For those using systemd, but wish to may use of the drift value stored in {{ic|/etc/adjtime}} and dont use NTP; they need to call {{ic|hwclock -- adjust}} on a regularly basis, perhaps by creating a cron job}}<br />
<br />
The software clock is very accurate but like most clocks is not perfectly accurate and will drift as well. Though rarely, the system clock can lose accuracy if the kernel skips interrupts. There are some tools to improve software clock accuracy:<br />
* [[NTP]] can synchronize the software clock of a GNU/Linux system with internet time servers using the Network Time Protocol. NTP can also adjust the interrupt frequency and the number of ticks per second to decrease system clock drift.<br />
* {{AUR|adjtimex}} in [[Arch User Repository|AUR]] can adjust kernel time variables like interrupt frequency to help improve the system clock time drift.<br />
<br />
== Resources ==<br />
<br />
* [http://www.linuxsa.org.au/tips/time.html Linux Tips - Linux, Clocks, and Time]<br />
* [http://www.twinsun.com/tz/tz-link.htm Sources for Time Zone and Daylight Saving Time Data] for {{Pkg|tzdata}}<br />
* [http://www.ucolick.org/~sla/leapsecs/timescales.html Time Scales]<br />
* [[Wikipedia:Time]]</div>PeterLhttps://wiki.archlinux.org/index.php?title=System_time&diff=233733System time2012-11-04T21:51:54Z<p>PeterL: /* Time Skew */</p>
<hr />
<div>[[es:TIMEZONE]]<br />
[[fa:زمان]]<br />
[[fr:Horloge]]<br />
[[ru:Time]]<br />
[[zh-CN:Time]]<br />
[[Category:Mainboards and BIOS]] <!-- with regard to the hardware clock --><br />
[[Category:Daemons and system services]] <!-- as the basis/rationale for NTP --><br />
{{Article summary start}}<br />
{{Article summary text|This article provides an introduction to the concept of keeping time on computers in general, and describes how clocks are configured and managed in Arch Linux.}}<br />
{{Article summary heading|Related}}<br />
{{Article summary wiki|Network Time Protocol}}<br />
{{Article summary end}}<br />
<br />
In an operating system the time (clock) is determined by four parts: Time value, Time standard, Time Zone, and DST ('''D'''aylight '''S'''aving '''T'''ime if applicable). This article explains what they are and how to read/set them. To ''maintain'' accurate system time on a network see [[Network Time Protocol]].<br />
<br />
== Hardware clock and system clock ==<br />
<br />
A computer has two clocks that need to be considered: the "Hardware clock" and the "System/software clock". <br />
<br />
'''Hardware clock''' (a.k.a. the Real Time Clock (RTC) or CMOS clock) stores the values of: Year, Month, Day, Hour, Minute, and the Seconds. It does not have the ability to store the time standard (localtime or UTC), nor whether DST is used. <br />
<br />
'''System clock''' (a.k.a. the software clock) keeps track of: Time, Time Zone, and DST if applicable. It is calculated by the Linux kernel as the number of seconds since midnight January 1st 1970, UTC. The initial value of the system clock is calculated from the hardware clock, dependent on the value of the HARDWARECLOCK variable defined in {{ic|/etc/rc.conf}} or for systems using systemd; the contents of {{ic|/etc/adjtime}}. After boot-up has completed the system clock runs independently of the hardware clock. The Linux kernel keeps track of the system clock by counting timer interrupts.<br />
<br />
=== Read clock ===<br />
<br />
To check the current hardware clock time and system clock time respectively (the hardware clock time is presented in localtime even if the hardware clock set to UTC):<br />
<br />
$ timedatectl status<br />
<br />
=== Set clock ===<br />
<br />
To set the system clock directly:<br />
<br />
# timedatectl set-time "2012-10-30 18:17:16"<br />
<br />
=== RTC clock ===<br />
<br />
Standard behavior of most operating systems is:<br />
<br />
* Set the system clock from the hardware clock on boot<br />
* Keep accurate time of the system clock with an [[Network Time Protocol daemon|NTP]] daemon<br />
* Set the hardware clock from the system clock on shutdown.<br />
<br />
== Time standard ==<br />
<br />
There are two time standards: '''localtime''' and '''C'''oordinated '''U'''niversal '''T'''ime ('''UTC'''). The localtime standard is dependent on the current ''time zone'', while UTC is the ''global'' time standard and is independent of time zone values. Though conceptually different, UTC is also known as GMT (Greenwich Mean Time).<br />
<br />
The standard used by hardware clock (CMOS clock, the time that appears in BIOS) is defined by the operating system. By default, Windows uses localtime, Mac OS uses UTC, and UNIX-like operating systems vary. An OS that uses the UTC standard, generally, will consider CMOS (hardware clock) time a UTC time (GMT, Greenwich time) and make an adjustment to it while setting the System time on boot according to your time zone. <br />
<br />
When using Linux it is beneficial to have the hardware clock set to the UTC standard and made known to all operating systems. Defining the hardware clock in Linux as UTC means that Daylight Saving Time will automatically be accounted for. If using the localtime standard the system clock will not be changed for DST occurrences assuming that another operating system will take care of the DST switch (and provided no NTP agent is operating).<br />
<br />
You can set the hardware clock time standard through the command line. You can check what you have set your Arch Linux install to use by:<br />
<br />
$ timedatectl status | grep local<br />
<br />
The hardware clock can be queried and set with the {{ic|hwclock}} command. To change the hardware clock time standard to localtime use:<br />
<br />
# timedatectl set-local-rtc 1<br />
<br />
And to set it to UTC use:<br />
<br />
# timedatectl set-local-rtc 0<br />
<br />
These will generate {{ic|/etc/adjtime}} automatically; no further configuration is required.<br />
<br />
During kernel startup, at the point when the RTC driver is loaded, the system clock may be set from the hardware clock. Whether this occurs or not depends on the hardware platform, the version of the kernel and kernel build options. If this does occur, at this point in the boot sequence, the hardware clock time is assumed to be UTC and the value of {{ic|/proc/sys/class/rtcN/hctosys}} (N=0,1,2,..) will be set to 1. Later during execution of {{ic|/etc/rc.sysinit}}, the system clock is set again from the hardware clock dependent on the value of HARDWARECLOCK or from systemd dependent on values in {{ic|/etc/adjtime}}. Hence, having the hardware clock using localtime may cause some unexpected behavior during the boot sequence; e.g system time going backwards, which is always a bad idea.<br />
<br />
=== UTC in Windows ===<br />
<br />
Using {{ic|regedit}}, add a {{ic|DWORD}} value with hexadecimal value {{ic|1}} to the registry:<br />
<br />
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\TimeZoneInformation\RealTimeIsUniversal<br />
<br />
Alternatively, create a {{ic|*.reg}} file (on the desktop) with the following content and double click it to import it into registry:<br />
<br />
Windows Registry Editor Version 5.00<br />
<br />
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\TimeZoneInformation]<br />
"RealTimeIsUniversal"=dword:00000001<br />
<br />
Windows XP and Windows Vista SP1 have support for setting the time standard as UTC and can be activated in the same way. However, there is a bug after resuming from the suspend/hibernation state that resets the clock to ''localtime''. For these operating systems it is recommended to use ''localtime''.<br />
<br />
Should Windows ask to update the clock due to DST changes, let it. It will leave the clock in UTC as expected, only correcting the displayed time.<br />
<br />
The hardware clock and system clock time may need to be [[#Set clock|updated]] after setting this value.<br />
<br />
=== Common problems ===<br />
<br />
A common source of problems is that different programs that interact with the real time clock do not agree whether or not it should be in UTC or local time. This tends to manifest itself in the time being consistently off by the same number of hours as your time zone differs from UTC.<br />
<br />
This problem can usually be solved by only configuring the real time device in one location, by removing the HARDWARECLOCK line from {{ic|/etc/rc.conf}} and instead configuring this value in {{ic|/etc/adjtime}}. This is the default configuration location for the hwclock program, and initscripts will use this value if HARDWARECLOCK is not set in rc.conf.<br />
<br />
Once this is configured correctly, make sure that both system time and the real time clock are up-to-date before the next reboot.<br />
<br />
== Time Zone ==<br />
<br />
To check the current zone:<br />
<br />
$ timedatectl status<br />
<br />
To list available zones:<br />
<br />
$ timedatectl list-timezones<br />
<br />
To change your time zone:<br />
<br />
# timedatectl set-timezone <Zone>/<SubZone><br />
<br />
Example:<br />
<br />
# timedatectl set-timezone Canada/Eastern<br />
<br />
== Time Skew ==<br />
<br />
Every clock has a value that differs from ''real time'' (the best representation of which being [[Wikipedia:International Atomic Time|International Atomic Time]]); no clock is perfect. A quartz-based electronic clock keeps imperfect time, but maintains a consistent inaccuracy. This base 'inaccuracy' is known as 'time skew' or 'time drift'. <br />
<br />
When the hardware clock is set with {{ic|hwclock}}, a new drift value is calculated in seconds per day. The drift value is calculated by using the difference between the new value set and the hardware clock value just before the set, taking into account the value of the previous drift value and the last time the hardware clock was set. The new drift value and the time when the clock was set is written to the file {{ic|/etc/adjtime}} overwriting the previous values. The hardware clock can be adjusted for drift when the command {{ic|hwclock --adjust}} is run; this occurs by default on shutdown if the {{ic|hwclock}} daemon is enabled. <br />
<br />
{{Note|If the hwclock has been set again less than 24 hours after a previous set, the drift is not recalculated as {{ic|hwclock}} considers the elapsed time period too short to accurately calculate the drift. It may be worth occasionally to stay in Linux so it gets calculated.}}<br />
<br />
If the hardware clock keeps losing or gaining time in large increments, it is possible that an invalid drift has been recorded (that is, if the hwclock daemon is enabled). This can happen if you have set the hardware clock time incorrectly or your [[#Time Standard|time standard]] is not synchronized with a Windows or Mac OS install. The drift value can be removed by removing the file {{ic|/etc/adjtime}}, then set the correct hardware clock and system clock time, and check if your [[#Time Standard|time standard]] is correct.<br />
<br />
The software clock is very accurate but like most clocks is not perfectly accurate and will drift as well. Though rarely, the system clock can lose accuracy if the kernel skips interrupts. There are some tools to improve software clock accuracy:<br />
* [[NTP]] can synchronize the software clock of a GNU/Linux system with internet time servers using the Network Time Protocol. NTP can also adjust the interrupt frequency and the number of ticks per second to decrease system clock drift.<br />
* {{AUR|adjtimex}} in [[Arch User Repository|AUR]] can adjust kernel time variables like interrupt frequency to help improve the system clock time drift.<br />
<br />
== Resources ==<br />
<br />
* [http://www.linuxsa.org.au/tips/time.html Linux Tips - Linux, Clocks, and Time]<br />
* [http://www.twinsun.com/tz/tz-link.htm Sources for Time Zone and Daylight Saving Time Data] for {{Pkg|tzdata}}<br />
* [http://www.ucolick.org/~sla/leapsecs/timescales.html Time Scales]<br />
* [[Wikipedia:Time]]</div>PeterLhttps://wiki.archlinux.org/index.php?title=System_time&diff=233732System time2012-11-04T21:47:31Z<p>PeterL: /* Time standard */</p>
<hr />
<div>[[es:TIMEZONE]]<br />
[[fa:زمان]]<br />
[[fr:Horloge]]<br />
[[ru:Time]]<br />
[[zh-CN:Time]]<br />
[[Category:Mainboards and BIOS]] <!-- with regard to the hardware clock --><br />
[[Category:Daemons and system services]] <!-- as the basis/rationale for NTP --><br />
{{Article summary start}}<br />
{{Article summary text|This article provides an introduction to the concept of keeping time on computers in general, and describes how clocks are configured and managed in Arch Linux.}}<br />
{{Article summary heading|Related}}<br />
{{Article summary wiki|Network Time Protocol}}<br />
{{Article summary end}}<br />
<br />
In an operating system the time (clock) is determined by four parts: Time value, Time standard, Time Zone, and DST ('''D'''aylight '''S'''aving '''T'''ime if applicable). This article explains what they are and how to read/set them. To ''maintain'' accurate system time on a network see [[Network Time Protocol]].<br />
<br />
== Hardware clock and system clock ==<br />
<br />
A computer has two clocks that need to be considered: the "Hardware clock" and the "System/software clock". <br />
<br />
'''Hardware clock''' (a.k.a. the Real Time Clock (RTC) or CMOS clock) stores the values of: Year, Month, Day, Hour, Minute, and the Seconds. It does not have the ability to store the time standard (localtime or UTC), nor whether DST is used. <br />
<br />
'''System clock''' (a.k.a. the software clock) keeps track of: Time, Time Zone, and DST if applicable. It is calculated by the Linux kernel as the number of seconds since midnight January 1st 1970, UTC. The initial value of the system clock is calculated from the hardware clock, dependent on the value of the HARDWARECLOCK variable defined in {{ic|/etc/rc.conf}} or for systems using systemd; the contents of {{ic|/etc/adjtime}}. After boot-up has completed the system clock runs independently of the hardware clock. The Linux kernel keeps track of the system clock by counting timer interrupts.<br />
<br />
=== Read clock ===<br />
<br />
To check the current hardware clock time and system clock time respectively (the hardware clock time is presented in localtime even if the hardware clock set to UTC):<br />
<br />
$ timedatectl status<br />
<br />
=== Set clock ===<br />
<br />
To set the system clock directly:<br />
<br />
# timedatectl set-time "2012-10-30 18:17:16"<br />
<br />
=== RTC clock ===<br />
<br />
Standard behavior of most operating systems is:<br />
<br />
* Set the system clock from the hardware clock on boot<br />
* Keep accurate time of the system clock with an [[Network Time Protocol daemon|NTP]] daemon<br />
* Set the hardware clock from the system clock on shutdown.<br />
<br />
== Time standard ==<br />
<br />
There are two time standards: '''localtime''' and '''C'''oordinated '''U'''niversal '''T'''ime ('''UTC'''). The localtime standard is dependent on the current ''time zone'', while UTC is the ''global'' time standard and is independent of time zone values. Though conceptually different, UTC is also known as GMT (Greenwich Mean Time).<br />
<br />
The standard used by hardware clock (CMOS clock, the time that appears in BIOS) is defined by the operating system. By default, Windows uses localtime, Mac OS uses UTC, and UNIX-like operating systems vary. An OS that uses the UTC standard, generally, will consider CMOS (hardware clock) time a UTC time (GMT, Greenwich time) and make an adjustment to it while setting the System time on boot according to your time zone. <br />
<br />
When using Linux it is beneficial to have the hardware clock set to the UTC standard and made known to all operating systems. Defining the hardware clock in Linux as UTC means that Daylight Saving Time will automatically be accounted for. If using the localtime standard the system clock will not be changed for DST occurrences assuming that another operating system will take care of the DST switch (and provided no NTP agent is operating).<br />
<br />
You can set the hardware clock time standard through the command line. You can check what you have set your Arch Linux install to use by:<br />
<br />
$ timedatectl status | grep local<br />
<br />
The hardware clock can be queried and set with the {{ic|hwclock}} command. To change the hardware clock time standard to localtime use:<br />
<br />
# timedatectl set-local-rtc 1<br />
<br />
And to set it to UTC use:<br />
<br />
# timedatectl set-local-rtc 0<br />
<br />
These will generate {{ic|/etc/adjtime}} automatically; no further configuration is required.<br />
<br />
During kernel startup, at the point when the RTC driver is loaded, the system clock may be set from the hardware clock. Whether this occurs or not depends on the hardware platform, the version of the kernel and kernel build options. If this does occur, at this point in the boot sequence, the hardware clock time is assumed to be UTC and the value of {{ic|/proc/sys/class/rtcN/hctosys}} (N=0,1,2,..) will be set to 1. Later during execution of {{ic|/etc/rc.sysinit}}, the system clock is set again from the hardware clock dependent on the value of HARDWARECLOCK or from systemd dependent on values in {{ic|/etc/adjtime}}. Hence, having the hardware clock using localtime may cause some unexpected behavior during the boot sequence; e.g system time going backwards, which is always a bad idea.<br />
<br />
=== UTC in Windows ===<br />
<br />
Using {{ic|regedit}}, add a {{ic|DWORD}} value with hexadecimal value {{ic|1}} to the registry:<br />
<br />
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\TimeZoneInformation\RealTimeIsUniversal<br />
<br />
Alternatively, create a {{ic|*.reg}} file (on the desktop) with the following content and double click it to import it into registry:<br />
<br />
Windows Registry Editor Version 5.00<br />
<br />
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\TimeZoneInformation]<br />
"RealTimeIsUniversal"=dword:00000001<br />
<br />
Windows XP and Windows Vista SP1 have support for setting the time standard as UTC and can be activated in the same way. However, there is a bug after resuming from the suspend/hibernation state that resets the clock to ''localtime''. For these operating systems it is recommended to use ''localtime''.<br />
<br />
Should Windows ask to update the clock due to DST changes, let it. It will leave the clock in UTC as expected, only correcting the displayed time.<br />
<br />
The hardware clock and system clock time may need to be [[#Set clock|updated]] after setting this value.<br />
<br />
=== Common problems ===<br />
<br />
A common source of problems is that different programs that interact with the real time clock do not agree whether or not it should be in UTC or local time. This tends to manifest itself in the time being consistently off by the same number of hours as your time zone differs from UTC.<br />
<br />
This problem can usually be solved by only configuring the real time device in one location, by removing the HARDWARECLOCK line from {{ic|/etc/rc.conf}} and instead configuring this value in {{ic|/etc/adjtime}}. This is the default configuration location for the hwclock program, and initscripts will use this value if HARDWARECLOCK is not set in rc.conf.<br />
<br />
Once this is configured correctly, make sure that both system time and the real time clock are up-to-date before the next reboot.<br />
<br />
== Time Zone ==<br />
<br />
To check the current zone:<br />
<br />
$ timedatectl status<br />
<br />
To list available zones:<br />
<br />
$ timedatectl list-timezones<br />
<br />
To change your time zone:<br />
<br />
# timedatectl set-timezone <Zone>/<SubZone><br />
<br />
Example:<br />
<br />
# timedatectl set-timezone Canada/Eastern<br />
<br />
== Time Skew ==<br />
<br />
Every clock has a value that differs from ''real time'' (the best representation of which being [[Wikipedia:International Atomic Time|International Atomic Time]]); no clock is perfect. A quartz-based electronic clock keeps imperfect time, but maintains a consistent inaccuracy. This base 'inaccuracy' is known as 'time skew' or 'time drift'. <br />
<br />
When the hardware clock is set with {{ic|hwclock}}, a new drift value is calculated in seconds per day. The drift value is calculated by using the difference between the new value set and the hardware clock value just before the set, taking into account the value of the previous drift value and the last time the hardware clock was set. The new drift value and the time when the clock was set is written to the file {{ic|/etc/adjtime}} overwriting the previous values. The hardware clock can be adjusted for drift when the command {{ic|hwclock --adjust}} is run; this occurs by default on shutdown if the {{ic|hwclock}} daemon is enabled. <br />
<br />
{{Note|If the hwclock has been set again less than 24 hours after a previous set, the drift is not recalculated as {{ic|hwclock}} considers the elapsed time period too short to accurately calculate the drift. It may be worth occasionally to stay in Linux so it gets calculated.}}<br />
<br />
If the hardware clock keeps losing or gaining time in large increments, it is possible that an invalid drift has been recorded. This can happen if you have set the hardware clock time incorrectly or your [[#Time Standard|time standard]] is not synchronized with a Windows or Mac OS install. The drift value can be removed by removing the file {{ic|/etc/adjtime}}, then set the correct hardware clock and system clock time, and check if your [[#Time Standard|time standard]] is correct.<br />
<br />
The software clock is very accurate but like most clocks is not perfectly accurate and will drift as well. Though rarely, the system clock can lose accuracy if the kernel skips interrupts. There are some tools to improve software clock accuracy:<br />
* [[NTP]] can synchronize the software clock of a GNU/Linux system with internet time servers using the Network Time Protocol. NTP can also adjust the interrupt frequency and the number of ticks per second to decrease system clock drift.<br />
* {{AUR|adjtimex}} in [[Arch User Repository|AUR]] can adjust kernel time variables like interrupt frequency to help improve the system clock time drift.<br />
<br />
== Resources ==<br />
<br />
* [http://www.linuxsa.org.au/tips/time.html Linux Tips - Linux, Clocks, and Time]<br />
* [http://www.twinsun.com/tz/tz-link.htm Sources for Time Zone and Daylight Saving Time Data] for {{Pkg|tzdata}}<br />
* [http://www.ucolick.org/~sla/leapsecs/timescales.html Time Scales]<br />
* [[Wikipedia:Time]]</div>PeterLhttps://wiki.archlinux.org/index.php?title=System_time&diff=233731System time2012-11-04T21:36:49Z<p>PeterL: /* Hardware clock and system clock */</p>
<hr />
<div>[[es:TIMEZONE]]<br />
[[fa:زمان]]<br />
[[fr:Horloge]]<br />
[[ru:Time]]<br />
[[zh-CN:Time]]<br />
[[Category:Mainboards and BIOS]] <!-- with regard to the hardware clock --><br />
[[Category:Daemons and system services]] <!-- as the basis/rationale for NTP --><br />
{{Article summary start}}<br />
{{Article summary text|This article provides an introduction to the concept of keeping time on computers in general, and describes how clocks are configured and managed in Arch Linux.}}<br />
{{Article summary heading|Related}}<br />
{{Article summary wiki|Network Time Protocol}}<br />
{{Article summary end}}<br />
<br />
In an operating system the time (clock) is determined by four parts: Time value, Time standard, Time Zone, and DST ('''D'''aylight '''S'''aving '''T'''ime if applicable). This article explains what they are and how to read/set them. To ''maintain'' accurate system time on a network see [[Network Time Protocol]].<br />
<br />
== Hardware clock and system clock ==<br />
<br />
A computer has two clocks that need to be considered: the "Hardware clock" and the "System/software clock". <br />
<br />
'''Hardware clock''' (a.k.a. the Real Time Clock (RTC) or CMOS clock) stores the values of: Year, Month, Day, Hour, Minute, and the Seconds. It does not have the ability to store the time standard (localtime or UTC), nor whether DST is used. <br />
<br />
'''System clock''' (a.k.a. the software clock) keeps track of: Time, Time Zone, and DST if applicable. It is calculated by the Linux kernel as the number of seconds since midnight January 1st 1970, UTC. The initial value of the system clock is calculated from the hardware clock, dependent on the value of the HARDWARECLOCK variable defined in {{ic|/etc/rc.conf}} or for systems using systemd; the contents of {{ic|/etc/adjtime}}. After boot-up has completed the system clock runs independently of the hardware clock. The Linux kernel keeps track of the system clock by counting timer interrupts.<br />
<br />
=== Read clock ===<br />
<br />
To check the current hardware clock time and system clock time respectively (the hardware clock time is presented in localtime even if the hardware clock set to UTC):<br />
<br />
$ timedatectl status<br />
<br />
=== Set clock ===<br />
<br />
To set the system clock directly:<br />
<br />
# timedatectl set-time "2012-10-30 18:17:16"<br />
<br />
=== RTC clock ===<br />
<br />
Standard behavior of most operating systems is:<br />
<br />
* Set the system clock from the hardware clock on boot<br />
* Keep accurate time of the system clock with an [[Network Time Protocol daemon|NTP]] daemon<br />
* Set the hardware clock from the system clock on shutdown.<br />
<br />
== Time standard ==<br />
<br />
There are two time standards: '''localtime''' and '''C'''oordinated '''U'''niversal '''T'''ime ('''UTC'''). The localtime standard is dependent on the current ''time zone'', while UTC is the ''global'' time standard and is independent of time zone values. Though conceptually different, UTC is also known as GMT (Greenwich Mean Time).<br />
<br />
The standard used by hardware clock (CMOS clock, the time that appears in BIOS) is defined by the operating system. By default, Windows uses localtime, Mac OS uses UTC, and UNIX-like operating systems vary. An OS that uses the UTC standard, generally, will consider CMOS (hardware clock) time a UTC time (GMT, Greenwich time) and make an adjustment to it while setting the System time on boot according to your time zone. <br />
<br />
When using Linux it is beneficial to have the hardware clock set to the UTC standard and made known to all operating systems. Defining the hardware clock in Linux as UTC means that Daylight Saving Time will automatically be accounted for. If using the localtime standard the system clock will not be changed for DST occurrences assuming that another operating system will take care of the DST switch (and provided no NTP agent is operating).<br />
<br />
You can set the hardware clock time standard through the command line. You can check what you have set your Arch Linux install to use by:<br />
<br />
$ timedatectl status | grep local<br />
<br />
The hardware clock can be queried and set with the {{ic|hwclock}} command. To change the hardware clock time standard to localtime use:<br />
<br />
# timedatectl set-local-rtc 1<br />
<br />
And to set it to UTC use:<br />
<br />
# timedatectl set-local-rtc 0<br />
<br />
These will generate {{ic|/etc/adjtime}} automatically; no further configuration is required.<br />
<br />
During kernel startup, at the point when the RTC driver is loaded, the system clock may be set from the hardware clock. Whether this occurs or not depends on the hardware platform, the version of the kernel and kernel build options. If this does occur, at this point in the boot sequence, the hardware clock time is assumed to be UTC and the value of {{ic|/proc/sys/class/rtcN/hctosys}} (N=0,1,2,..) will be set to 1. Later during execution of {{ic|/etc/rc.sysinit}}, the system clock is set again from the hardware clock dependent on the value of HARDWARECLOCK. Hence, having the hardware clock using localtime may cause some unexpected behavior during the boot sequence; e.g system time going backwards, which is always a bad idea.<br />
<br />
=== UTC in Windows ===<br />
<br />
Using {{ic|regedit}}, add a {{ic|DWORD}} value with hexadecimal value {{ic|1}} to the registry:<br />
<br />
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\TimeZoneInformation\RealTimeIsUniversal<br />
<br />
Alternatively, create a {{ic|*.reg}} file (on the desktop) with the following content and double click it to import it into registry:<br />
<br />
Windows Registry Editor Version 5.00<br />
<br />
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\TimeZoneInformation]<br />
"RealTimeIsUniversal"=dword:00000001<br />
<br />
Windows XP and Windows Vista SP1 have support for setting the time standard as UTC and can be activated in the same way. However, there is a bug after resuming from the suspend/hibernation state that resets the clock to ''localtime''. For these operating systems it is recommended to use ''localtime''.<br />
<br />
Should Windows ask to update the clock due to DST changes, let it. It will leave the clock in UTC as expected, only correcting the displayed time.<br />
<br />
The hardware clock and system clock time may need to be [[#Set clock|updated]] after setting this value.<br />
<br />
=== Common problems ===<br />
<br />
A common source of problems is that different programs that interact with the real time clock do not agree whether or not it should be in UTC or local time. This tends to manifest itself in the time being consistently off by the same number of hours as your time zone differs from UTC.<br />
<br />
This problem can usually be solved by only configuring the real time device in one location, by removing the HARDWARECLOCK line from {{ic|/etc/rc.conf}} and instead configuring this value in {{ic|/etc/adjtime}}. This is the default configuration location for the hwclock program, and initscripts will use this value if HARDWARECLOCK is not set in rc.conf.<br />
<br />
Once this is configured correctly, make sure that both system time and the real time clock are up-to-date before the next reboot.<br />
<br />
== Time Zone ==<br />
<br />
To check the current zone:<br />
<br />
$ timedatectl status<br />
<br />
To list available zones:<br />
<br />
$ timedatectl list-timezones<br />
<br />
To change your time zone:<br />
<br />
# timedatectl set-timezone <Zone>/<SubZone><br />
<br />
Example:<br />
<br />
# timedatectl set-timezone Canada/Eastern<br />
<br />
== Time Skew ==<br />
<br />
Every clock has a value that differs from ''real time'' (the best representation of which being [[Wikipedia:International Atomic Time|International Atomic Time]]); no clock is perfect. A quartz-based electronic clock keeps imperfect time, but maintains a consistent inaccuracy. This base 'inaccuracy' is known as 'time skew' or 'time drift'. <br />
<br />
When the hardware clock is set with {{ic|hwclock}}, a new drift value is calculated in seconds per day. The drift value is calculated by using the difference between the new value set and the hardware clock value just before the set, taking into account the value of the previous drift value and the last time the hardware clock was set. The new drift value and the time when the clock was set is written to the file {{ic|/etc/adjtime}} overwriting the previous values. The hardware clock can be adjusted for drift when the command {{ic|hwclock --adjust}} is run; this occurs by default on shutdown if the {{ic|hwclock}} daemon is enabled. <br />
<br />
{{Note|If the hwclock has been set again less than 24 hours after a previous set, the drift is not recalculated as {{ic|hwclock}} considers the elapsed time period too short to accurately calculate the drift. It may be worth occasionally to stay in Linux so it gets calculated.}}<br />
<br />
If the hardware clock keeps losing or gaining time in large increments, it is possible that an invalid drift has been recorded. This can happen if you have set the hardware clock time incorrectly or your [[#Time Standard|time standard]] is not synchronized with a Windows or Mac OS install. The drift value can be removed by removing the file {{ic|/etc/adjtime}}, then set the correct hardware clock and system clock time, and check if your [[#Time Standard|time standard]] is correct.<br />
<br />
The software clock is very accurate but like most clocks is not perfectly accurate and will drift as well. Though rarely, the system clock can lose accuracy if the kernel skips interrupts. There are some tools to improve software clock accuracy:<br />
* [[NTP]] can synchronize the software clock of a GNU/Linux system with internet time servers using the Network Time Protocol. NTP can also adjust the interrupt frequency and the number of ticks per second to decrease system clock drift.<br />
* {{AUR|adjtimex}} in [[Arch User Repository|AUR]] can adjust kernel time variables like interrupt frequency to help improve the system clock time drift.<br />
<br />
== Resources ==<br />
<br />
* [http://www.linuxsa.org.au/tips/time.html Linux Tips - Linux, Clocks, and Time]<br />
* [http://www.twinsun.com/tz/tz-link.htm Sources for Time Zone and Daylight Saving Time Data] for {{Pkg|tzdata}}<br />
* [http://www.ucolick.org/~sla/leapsecs/timescales.html Time Scales]<br />
* [[Wikipedia:Time]]</div>PeterLhttps://wiki.archlinux.org/index.php?title=Daemons&diff=174785Daemons2011-12-17T20:27:05Z<p>PeterL: /* List of Daemons */</p>
<hr />
<div>[[Category:Boot process (English)]]<br />
[[Category:Daemons and system services (English)]]<br />
{{i18n|Daemon}}<br />
[[de:Daemons]]<br />
[[ro:Daemon]]<br />
<br />
A [[Wikipedia:Daemon (computing)|daemon]] is a program that runs in the background, waiting for events to occur and offering services. A good example is a web server that waits for a request to deliver a page or a ssh server waiting for someone trying to log in. While these are full featured applications, there are daemons whose work is not that visible. Daemons are for tasks like writing messages into a log file (e.g. syslog, metalog) or keeping your system time accurate (e.g. [[Network Time Protocol daemon|ntpd]]).<br />
<br />
{{Note|The word daemon is sometimes used for a class of programs that are started at boot but have no process which remains in memory. They are called daemons simply because they utilize the same startup/shutdown framework (e.g. {{ic|/etc/rc.d/}} scripts) used to start traditional daemons. For example, the {{ic|/etc/rc.d}} scripts for ''alsa'' and ''cpufreq'' provide persistent configuration support for their perspective kernel modules but do not start additional background processes to service requests or respond to events.<br />
<br />
From the user's perspective the distinction is typically not significant unless the user tries to look for the "daemon" in a process list.<br />
}}<br />
<br />
==Starting on Boot==<br />
A default install of Arch Linux will leave you with very few services (or daemons) enabled during boot. You can add or remove services by editing the {{ic|DAEMONS}} array in your [[rc.conf]] file. It will initially look something like this:<br />
DAEMONS=(syslog-ng network netfs crond)<br />
<br />
They will start in the order you have them listed. You can disable one and keep it in the array by prefixing it with an exclamation mark ({{ic|!}}). You can also have them start in the background by adding the {{ic|@}} symbol in front of it.<br />
<br />
Daemon scripts are stored in {{ic|/etc/rc.d/}}. You can print the list of all the available daemons on your system, along with their current status, with:<br />
$ rc.d list<br />
<br />
==Performing daemon actions manually==<br />
Every daemon has a series of actions that can be called with specific commands: usually there are at least {{ic|start}}, {{ic|stop}}, and {{ic|restart}}. You can issue each with:<br />
# /etc/rc.d/''daemon-name'' {start|stop|restart|...}<br />
A completely equivalent way is:<br />
# rc.d {start|stop|restart|...} ''daemon-name-1'' ''daemon-name-2'' ''daemon-name-3'' ...<br />
which, as it is clear from the example, works also with a list of daemons, calling for each the given action.<br />
<br />
For a list of all the available commands for a specific daemon, check its documentation, or just open the script in a text viewer.<br />
<br />
==Essentials==<br />
You do not have to add any more services, if you do not feel the need. However, a typical desktop user will add at least [[CUPS]] and [[dbus]]. As you install new services, you will have to manually add them to the {{ic|DAEMONS}} array in {{ic|/etc/rc.conf}}. (The {{ic|DAEMONS}} array is at the end of the default {{ic|rc.conf}} file.)<br />
<br />
==Starting Daemons in Background==<br />
This is helpful for starting a service and letting the next service start before the previous one has finished. Which services to start background depends on your needs. Do not background anything you need immediately. Here is an example:<br />
DAEMONS=(syslog-ng gensplash dbus network netfs @avahi-daemon @samba @crond @openntpd @cupsd @mpd)<br />
<br />
Starting {{ic|openntpd}} in the background could lead to synchronization errors between the actual time and the time stored on your computer. If you recognize an increasing time difference between your desktop clock and the actual time, try to start the {{ic|openntpd}} daemon normally and not in the background.<br />
<br />
==Rc.conf GUI Frontends==<br />
[[Rc.conf GUI Frontends]] allow you to easily change settings in {{ic|/etc/rc.conf}} using graphical application.<br />
<br />
==List of Daemons==<br />
Here is a list of daemons. Note that any package can provide a daemon, so this list will never be complete. Please feel free to add any missing daemons here, in alphabetical order.<br />
{| border="1"<br />
!Daemon!!Description<br />
|-<br />
|[[Acpid|acpid]]||Delivers ACPI events.<br />
|-<br />
|[[Advanced Linux Sound Architecture|alsa]]||Advanced Linux Sound Architecture; provides device drivers for sound cards.<br />
|-<br />
|atd||Run jobs queued for later execution.<br />
|-<br />
|[[Avahi|avahi-daemon]]||Allows programs to automatically find local network services.<br />
|-<br />
|[[Avahi|avahi-dnsconfd]]||<br />
|-<br />
|crond||Daemon to schedule and time events. The daemon name ''crond'' is used by at least two packages, {{Pkg|cronie}} and {{Pkg|dcron}}. See [[Cron]] for more information.<br />
|-<br />
|[[CUPS|cupsd]]||Common UNIX Printing System daemon.<br />
|-<br />
|[[D-Bus|dbus]]||Message bus system for software communication.<br />
|-<br />
|[[FAM|fam]]||File Alteration Monitor. (deprecated)<br />
|-<br />
|[[Fbsplash|fbsplash]]||Graphical boot splash screen for the user.<br />
|-<br />
|[[GDM|gdm]]||Gnome Display Manager (Login Screen)<br />
|-<br />
|[[Console Mouse Support|gpm]]||Console mouse support.<br />
|-<br />
|[[Fbsplash|gensplash]]||(see fbsplash)<br />
|-<br />
|[[HAL|hal]]||Hardware Abstraction Layer. (Deprecated)<br />
|-<br />
|[[LAMP|httpd]]||Apache HTTP Server (Web Server)<br />
|-<br />
|[[hwclock]]||Not a daemon as such, but on shutdown, updates hwclock to compensate for drift. Only run this daemon if ntpd is not running as both daemons adjust the hardware clock.<br />
|-<br />
|[[MDADM|mdadm]]||MD Administration (Linux Software RAID).<br />
|-<br />
|[[Music Player Daemon|mpd]]||Music Player Daemon.<br />
|-<br />
|[[MySQL|mysqld]]||MySQL database server.<br />
|-<br />
|netfs||Mounts network file systems.<br />
|-<br />
|[[Configuring_Network|network]]||To bring up the network connections.<br />
|-<br />
|[[NetworkManager|networkmanager]]||Replace network, and provide configuration and detection for automatic network connections.<br />
|-<br />
|nsyslogd||<br />
|-<br />
|[[Network Time Protocol daemon|ntpd]]||Network Time Protocol daemon (client and server).<br />
|-<br />
|[[OpenNTPD|openntpd]]||alternate Network Time Protocol daemon (client and server).<br />
|-<br />
|[[Pure-FTPD|pure-ftpd]]||FTP server.<br />
|-<br />
|[[Powernowd|powernowd]]||To adjust speed of CPU depending on system load. See also [[CPU_Frequency_Scaling]]<br />
|-<br />
|[[Rsyslog|rsyslogd]]||The latest version of a system logger.<br />
|-<br />
|[[SLiM|slim]]||Simple Login Manager<br />
|-<br />
|[[Samba|samba]]||File and print services for Microsoft Windows clients.<br />
|-<br />
|[[USB_Scanner_Support|saned]]||To share the scanner system over network.<br />
|-<br />
|[[Lm_sensors|sensors]]||Hardware (temperature, fans etc) monitoring.<br />
|-<br />
|[[SMART|smartd]]||Self-Monitoring, Analysis, and Reporting Technology (S.M.A.R.T) Hard Disk Monitoring<br />
|-<br />
|[[Secure Shell|sshd]]||OpenSSH (secure shell) daemon.<br />
|-<br />
|stbd ||This daemon was previously necessary for gnome-system-tools. However, as of gnome-tools 2.28, it is no longer needed.<br />
|-<br />
|syslogd||This was the older and basic system logger.<br />
|-<br />
|[[Syslog-ng|syslog-ng]]||System logger next generation.<br />
|-<br />
|[[Timidity|timidity++]]||Software synthesizer for MIDI.<br />
|-<br />
|[[VirtualBox|vboxdrv]]||Necessary to run VirtualBox.<br />
|-<br />
|[[Very Secure FTP Daemon|vsftpd]]||FTP server.<br />
|-<br />
|[[Wicd|wicd]]||Combine with dbus to replace network, a lightweight alternative to NetworkManager.<br />
|-<br />
|}<br />
<br />
==See also==<br />
Examples for [[writing rc.d scripts]]</div>PeterLhttps://wiki.archlinux.org/index.php?title=System_time&diff=174784System time2011-12-17T20:23:07Z<p>PeterL: /* Other Details */</p>
<hr />
<div>[[Category:Mainboards and BIOS (English)]] <!-- with regard to the hardware clock --><br />
[[Category:Daemons and system services (English)]] <!-- as the basis/rationale for NTP --><br />
{{i18n|Time}}<br />
{{Article summary start}}<br />
{{Article summary text|This article provides an introduction to the concept of keeping time on computers in general, and describes how clocks are configured and managed in Arch Linux.}}<br />
{{Article summary heading|Related}}<br />
{{Article summary wiki|Network Time Protocol}}<br />
{{Article summary wiki|rc.conf}}<br />
{{Article summary end}}<br />
<br />
This article explains how the time is read and set. The hardware clock (a.k.a. the Real Time Clock (RTC) or CMOS clock) and the system clock need to be set up correctly to maintain proper time. For ''maintaining'' accurate system time see [[Network Time Protocol]].<br />
<br />
== About ==<br />
<br />
The hardware clock stores the values of: Year, Month, Day, Hour, Minute, and the Seconds. The hardware clock time value will be of either of two standards: either the '''localtime''' standard, or the '''C'''oordinated '''U'''niversal '''T'''ime ('''UTC''') standard (also known as GMT, though conceptually different). The localtime standard is dependent on the current ''time zone'', while UTC is the ''global'' time standard and is independent of time zone values. The hardware clock can only store time values and does not have the ability to store the time standard (localtime or UTC), nor whether '''D'''aylight '''S'''aving '''T'''ime ('''DST''') is used.<br />
<br />
The hardware clock time standard (localtime or UTC) can be defined to most operating system's system clocks. By default, Windows uses localtime, Mac OS uses UTC, and UNIX-like operating systems vary. The system clock (a.k.a. the software clock) runs independent of the hardware clock and keeps track of: Time, Time Zone, and DST if applicable. Standard behavior of most operating systems is to set the system clock from the hardware clock on boot, keep accurate time of the system clock with an [[Network Time Protocol daemon|NTP]] daemon. When [[Network Time Protocol daemon|NTP]] daemon is running the hardware clock is periodically updated from system clock. <br />
<br />
When using Linux it is beneficial to have the hardware clock set to the UTC standard and made known to all operating systems. Defining the hardware clock in Linux as UTC means that Daylight Savings Time will automatically be accounted for. If using the localtime standard the system clock will not be changed for DST occurances assuming that another operating system will take care of the DST switch (and provided no NTP agent is operating).<br />
<br />
== Time Standard ==<br />
<br />
You can set the hardware clock time standard through the command line. You can check what you have set your Arch Linux install to use by:<br />
<br />
$ grep ^HARDWARECLOCK /etc/rc.conf<br />
<br />
The hardware clock can be queried and set with the {{ic|hwclock}} command. To immediately change the hardware clock time standard to localtime use:<br />
<br />
# hwclock --localtime<br />
<br />
And to set it to UTC use:<br />
<br />
# hwclock --utc<br />
<br />
The time standard that the hardware clock uses will also need to be entered in your Arch Linux system configuration ([[rc.conf]]) so that the system clock will be correctly set on boot:<br />
<br />
HARDWARECLOCK="localtime"<br />
<br />
or<br />
<br />
HARDWARECLOCK="UTC"<br />
<br />
== Time Zone ==<br />
<br />
Be sure that your time zone is set correctly in {{ic|/etc/rc.conf}}. This is necessary not only for the localtime to be set correctly but also for other programs you may use. You can do this by:<br />
<br />
$ grep ^TIMEZONE /etc/rc.conf<br />
<br />
You can find the time zones listed in {{ic|/usr/share/zoneinfo/}} and then you will need to find a major city that exists to your time zone. If you live in a specialized time zone area these will be listed in sub-directories. An example configuration:<br />
<br />
TIMEZONE="America/Chicago"<br />
<br />
The new time zone will be taken into effect when you reboot. To change the timezone immediately you will need to link or copy it to {{ic|/etc/localtime}}:<br />
<br />
# cp /usr/share/zoneinfo/America/Chicago /etc/localtime<br />
<br />
When you [[#Time Set|set the hardware clock]] the new time zone will be take used.<br />
<br />
== Time Set ==<br />
<br />
The hardware clock can be set either directly or from the system clock. To check the current hardware clock time and system clock time respectively (the hardware clock time is presented in localtime even if the hardware clock set to UTC):<br />
<br />
# hwclock --show<br />
$ date<br />
<br />
To set the hardware clock directly (the argument must be in local time, even if you keep your hardware clock in UTC.):<br />
<br />
# hwclock --set --date="YYYY-MM-DD hh:mm:ss"<br />
<br />
To set the system clock:<br />
<br />
# date MMDDhhmmYYYY<br />
<br />
The hardware clock can be set from the system clock and vice versa:<br />
<br />
# hwclock --systohc<br />
# hwclock --hctosys<br />
<br />
== Time Skew ==<br />
<br />
Every clock has a value that differs from ''real time'' (the best representation of which being [[Wikipedia:International Atomic Time|International Atomic Time]]), no clock is perfect. A quartz based electronic clock keeps imperfect time, but maintains a consistent inaccuracy. This base 'inaccuracy' is known as 'time skew' or 'time drift'. When the hardware clock is set with {{ic|hwclock}}, a new drift value is calculated in seconds per day. The drift value is calculated by using the difference between the new value set and the hardware clock value just before the set, taking into account the value of the previous drift value and the last time time the hardware clock was set. The new drift value and the time when the clock was set is written to the file {{ic|/var/lib/hwclock/adjtime}} overwriting the previous values.<br />
<br />
{{Note|If the hwclock has been set again less than 24 hours after a previous set, the drift is not recalculated as {{ic|hwclock}} considers the elaspsed time period too short to accurately calculate the drift.}}<br />
<br />
If the hardware clock keeps losing or gaining time in large increments, it is possible that an invalid drift has been recorded. This can happen if you have set the hardware clock time incorrectly or your [[#Time Standard|time standard]] is not synchronized with a Windows or Mac OS install. The drift value can be removed by removing the file {{ic|/var/lib/hwclock/adjtime}}, then set the correct hardware clock and system clock time, and check if your [[#Time Standard|time standard]] is correct.<br />
<br />
The system clock is calculated by the Linux kernel as the number of seconds since midnight January 1st 1970 UTC. The initial value of the system clock is calculated from the hardware clock, dependent on the value of the HARDWARECLOCK defined in {{ic|/etc/rc.conf}}. Once power up has completed the system clock runs independently of the hardware clock. The Linux kernel keeps track of the system clock by counting timer interrupts. The software clock is very accurate but like most clocks is not perfectly accurate and will drift as well. Though rarely, the system clock can lose accuracy if the kernel skips interrupts. System clocks can be kept on accurate time by using [[NTP]]. NTP can also will adjust the interrupt frequency and the number of ticks per second to decrease system clock drift.<br />
<br />
== UTC in Windows ==<br />
<br />
Add the DWORD value:<br />
<br />
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\TimeZoneInformation\RealTimeIsUniversal<br />
<br />
with hexadecimal value 1 to the registry (through regedit). Windows XP and Windows Vista SP1 have support for setting the time standard as {{ic|UTC}} and can be activated in the same way however there is a bug after resuming from the suspend/hibernation state that resets the clock to {{ic|localtime}}. For these operating systems it is recommended to use {{ic|localtime}}.<br />
<br />
The hardware clock and system clock time may need to be [[#Setting the time|updated]] after setting this value.<br />
<br />
== Other Details ==<br />
<br />
* 32-bit Linux systems will stop working in 2038. Since system time is recorded as a 32-bit integer (the number of seconds since 1970-01-01) it's limitation will extend only this long.<br />
* If you regularly shutdown/reboot your computer numerous times in a day the recorded drift value will never get calculated, it may be worth occasionally to stay in Linux so it gets calculated.<br />
* The [[Arch User Repository|AUR]] package {{AUR|adjtimex}} can adjust kernel time variables like interupt frequency to help improve the system clock time drift.<br />
* During kernel startup, at the point when the rtc driver is loaded, the system clock may be set from the hardware clock. Whether this occurs or not depends on the hardware platform, the version of the kernel and kernel build options. If this does occur, at this point in the boot sequence, the hardware clock time is assumed to be UTC and the value of {{ic|/proc/sys/class/rtcN/hctosys}} (N=0,1,2,..) will be set to 1. Later during execution of {{ic|/etc/rc.sysinit}}, the system clock is set again from the hardware clock dependent on the value of HARDWARECLOCK. Hence, having the hardware clock using localtime may cause some unexpected behaviour during the boot sequence; e.g system time going backwards which is always a bad idea,<br />
* The hardware clock is adjusted for drift only when the command {{ic|hwclock --adjust}} is run. Currently (Dec 2011) this only occurs if the {{ic|hwclock}} daemon is enabled and then only during shutdown. <br />
* Running the {{ic|hwclock}} daemon is not recommended if running the {{AUR|NTP}} daemon as the {{AUR|NTP}} daemon also adjusts the hardware clock.<br />
<br />
== It's About 'Time' == <br />
<!-- This was the introduction to the original 'Time' article by [[User:Android]]; kept for nostalgia's sake. --><br />
<br />
Our concept of time speaks much more to our limited perception than it does to the nature of what we observe. Time is clearly the most fertile ground for a fundamental shift in the human conception of the objective natural universe.<br />
<br />
Time has been measured since the beginning of time, at least as a human concept. The most obvious natural marker of the passage of time is the progression of day and night. The "day" was the first known measure of time and still forms a fundamental part of timekeeping. Other cyclic natural phenomena are also historically associated with time; the word "tide" comes from a common etymological root. Even with computer timekeeping, the day is a fundamental concept.<br />
<br />
As the measurement of time has improved, standard measures of time have had to be revised. The "leapyear" accounts for the fact that the Earth's orbit around the sun is not exactly 365 days. With the advent of atomic clocks in the 1960s, it became clear that the Earth's daily rotation was gradually slowing down (primarily due to tidal friction). The definition of the second in terms of cesium atom oscillations is the basis of the time standard known as [[Wikipedia:International Atomic Time|'''I'''nternational '''A'''tomic '''T'''ime]], or '''TAI'''.<br />
<br />
The slow and irregular increase in the amount of time comprising a day occasionally causes problems with the POSIX definition of a day as 86400 seconds. This led to the introduction of the "leapsecond" in 1972. Occasionally a second must be inserted into the normally defined UTC sequence in order to keep it synchronized with TAI.<br />
<br />
== Resources ==<br />
<br />
* [http://www.linuxsa.org.au/tips/time.html Linux Tips - Linux, Clocks, and Time]<br />
* [http://www.twinsun.com/tz/tz-link.htm Sources for Time Zone and Daylight Saving Time Data] for {{Pkg|tzdata}}<br />
* [http://www.ucolick.org/~sla/leapsecs/timescales.html Time Scales]<br />
* [[Wikipedia:Time]]</div>PeterLhttps://wiki.archlinux.org/index.php?title=Talk:System_time&diff=174783Talk:System time2011-12-17T20:21:26Z<p>PeterL: /* New initscripts and hwclock daemon */</p>
<hr />
<div>Gog, why is it you're so determined to delete this?<br />
<br />
I'm working on it and its a valid topic.<br />
<br />
johnea<br />
:because it reads like a blog and its kinda wierd. compare it to the rest of the stuff. how to install this that BAM PHILOSOPHICAL BREAKTHROUGH<br />
<br />
Ya know, a lot of the stuff on this wiki is just plain out of date.<br />
<br />
Don't you think it would be more productive to try to find stuff that just doesn't even apply to the current arch system and update or delete that.<br />
<br />
Take a look at Arch64, there are 3 or 4 different ways of implimenting this and there is no contextual information on how or when these work together or when they are mutually exclusive. For instance, the "Current State of Arch64 Development" which is 2 years old.<br />
<br />
A lot of times things are at first done by individuals, then eventually some variation on the theme is included in the standard distribution. A wiki article describes the original work, but it's never updated to indicate that this is all build-in now.<br />
<br />
There's a lot of specific information, but much of it is not current, and almost none of it is tied together.<br />
<br />
It seems a lot of work could go into making the wiki more organized and relating the various topics to each other.<br />
<br />
This would make a resource for arch users new and old.<br />
<br />
With all of this lacking in the current documentation, I don't understand the need to be some kind of self expression censor.<br />
<br />
this article started when I was investigating posix time and the recently passed leap second.<br />
<br />
The fluffy stuff at the beginning is an introduction to the details.<br />
<br />
The next bit is a copy and paste from an email exchange with Jamie Zawinski and then some links saved at the bottom so they don't get lost before coming back around to it. The original intent of the article is to be about 3 times the current length.<br />
<br />
After being a degreed EE in industry for 26 years it gets pretty fucking boring reading a bunch of acronyme enhanced techno bable in run-on third person sententences with the drilled down lack of context of an autistic plastic pocket protector.<br />
<br />
Additionally the "normal" non-weird style lends itself to almost immediate obsolescence because of its lack of context.<br />
<br />
I'm not sure what you do with your days, but over here there's a mortgage, a kid with the flu, three projects that need attention for clients, past due taxes, and plenty of other "normal" duties vying for my time. If I spend time writing about time keeping in unix computing, I want it to be fun as well as informative.<br />
<br />
I didn't realize the arch community had such strict standards of boringness.<br />
<br />
I've been running this distro for 6 years, pretty much every day. I'm not a maintainer, but I am a reasonably knowledgable user. I'd like to spread some of that knowledge to help arch users understand how their whole system fits together. A comprehensive understanding is not reached by each specific detail alone, it requires context and inter-relation. <br />
<br />
The wiki should be THE ARCH BOOK. This requires that each article be maintained, not just a bunch of details that are correct in the moment but superfluous 6 months down the road. Otherwise it will always be in a shambles and mostly out of date with no cohesive vision that guides the reader or future contributions.<br />
<br />
That's my bit. <br />
<br />
Best of luck...<br />
<br />
johnea<br />
<br />
==<s>New initscripts and hwclock daemon</s>==<br />
With the latest initscripts package, the hardware clock is kept updated differently than how it's explained here (for example it's not in rc.shutdown any longer), I am still trying to understand well, so I cannot update the article by myself. For now I'm marking it as out of date. -- [[User:Kynikos|Kynikos]] 16:09, 3 May 2011 (EDT)<br />
:At the moment I link the bug report that seems to be responsible for this change: {{Bug|13684}}. -- [[User:Kynikos|Kynikos]] 16:39, 3 May 2011 (EDT)<br />
::Understood and updated (also contributed by PeterL). -- [[User:Kynikos|Kynikos]] 06:17, 9 June 2011 (EDT)<br />
:::Updated references to setting system time from hardware clock as I noticed things have changed again in the latest initscripts [[User:PeterL|PeterL]] 20:20 17 Dec 2011 (GMT)<br />
<br />
==Note in the About section==<br />
Hi there. I just got throught installing arch on a dualboot system. I saw how I can configure all this time-stuff, but didn't get what it is I'm supposed to be doing. (No problem following instructions, but.. what's the current situation, and what's the target?) Found this page, and read it. I only understood clock and time. So I played around (with UTC, changing BIOS clock, windows clock, linux clock, rebooted and looked at how the other clocks reacted). Then it was ovious. Reading throught the about section again I was puzzled why I didn't understand the concept perfectly on the first read, because it's all there, in detail. <br />
<br />
So I added this note. I couldn't improve the About section itself, because it's all there already. But it's a lot of text with a lot of clocks (;) . I didn't want to dumb it down, and adding to it doesn't help the beginner, it's just more clocks. So I thought I'll just add a simple version of what's going on, seperate from the detailed information<br />
<br />
But I know it's dublicated information, so someone might just delete it for that reason, and this is why i write here. Please don't delete it. It's a little bit of a chicken and egg problem, at least for me. This article needs a very basic explanation of what going on.<br />
:Please sign your edits in talk pages.<br />
:Don't worry, it's going to stay, I've just reworded it a bit and removed the Note template since it can't be considered a note. -- [[User:Kynikos|Kynikos]] 07:08, 15 October 2011 (EDT)<br />
===<s>How to set Windows to use UTC</s>===<br />
Is there a reason we don't provide info on [https://wiki.archlinux.org/index.php/Rc.conf#Localization how to set Windows to use UTC] here? Can I just copy-paste the note? -- [[User:Karol|Karol]] 09:02, 28 November 2011 (EST)<br />
:You know that every time you write the word Win**** in the ArchWiki, god kills a kitten!<br />
:Yeah copy-paste it ;)<br />
:-- [[User:Kynikos|Kynikos]] 05:12, 29 November 2011 (EST)<br />
::I don't like cats, I prefer llamas. Windows Windows Windows Windows ;P<br />
::[https://wiki.archlinux.org/index.php?title=Time&diff=171563&oldid=170247 Note added]. Closing. -- [[User:Karol|Karol]] 07:00, 29 November 2011 (EST)</div>PeterLhttps://wiki.archlinux.org/index.php?title=System_time&diff=174782System time2011-12-17T20:17:29Z<p>PeterL: Added note about not running the hwclock daemon and the ntp daemon at same time.</p>
<hr />
<div>[[Category:Mainboards and BIOS (English)]] <!-- with regard to the hardware clock --><br />
[[Category:Daemons and system services (English)]] <!-- as the basis/rationale for NTP --><br />
{{i18n|Time}}<br />
{{Article summary start}}<br />
{{Article summary text|This article provides an introduction to the concept of keeping time on computers in general, and describes how clocks are configured and managed in Arch Linux.}}<br />
{{Article summary heading|Related}}<br />
{{Article summary wiki|Network Time Protocol}}<br />
{{Article summary wiki|rc.conf}}<br />
{{Article summary end}}<br />
<br />
This article explains how the time is read and set. The hardware clock (a.k.a. the Real Time Clock (RTC) or CMOS clock) and the system clock need to be set up correctly to maintain proper time. For ''maintaining'' accurate system time see [[Network Time Protocol]].<br />
<br />
== About ==<br />
<br />
The hardware clock stores the values of: Year, Month, Day, Hour, Minute, and the Seconds. The hardware clock time value will be of either of two standards: either the '''localtime''' standard, or the '''C'''oordinated '''U'''niversal '''T'''ime ('''UTC''') standard (also known as GMT, though conceptually different). The localtime standard is dependent on the current ''time zone'', while UTC is the ''global'' time standard and is independent of time zone values. The hardware clock can only store time values and does not have the ability to store the time standard (localtime or UTC), nor whether '''D'''aylight '''S'''aving '''T'''ime ('''DST''') is used.<br />
<br />
The hardware clock time standard (localtime or UTC) can be defined to most operating system's system clocks. By default, Windows uses localtime, Mac OS uses UTC, and UNIX-like operating systems vary. The system clock (a.k.a. the software clock) runs independent of the hardware clock and keeps track of: Time, Time Zone, and DST if applicable. Standard behavior of most operating systems is to set the system clock from the hardware clock on boot, keep accurate time of the system clock with an [[Network Time Protocol daemon|NTP]] daemon. When [[Network Time Protocol daemon|NTP]] daemon is running the hardware clock is periodically updated from system clock. <br />
<br />
When using Linux it is beneficial to have the hardware clock set to the UTC standard and made known to all operating systems. Defining the hardware clock in Linux as UTC means that Daylight Savings Time will automatically be accounted for. If using the localtime standard the system clock will not be changed for DST occurances assuming that another operating system will take care of the DST switch (and provided no NTP agent is operating).<br />
<br />
== Time Standard ==<br />
<br />
You can set the hardware clock time standard through the command line. You can check what you have set your Arch Linux install to use by:<br />
<br />
$ grep ^HARDWARECLOCK /etc/rc.conf<br />
<br />
The hardware clock can be queried and set with the {{ic|hwclock}} command. To immediately change the hardware clock time standard to localtime use:<br />
<br />
# hwclock --localtime<br />
<br />
And to set it to UTC use:<br />
<br />
# hwclock --utc<br />
<br />
The time standard that the hardware clock uses will also need to be entered in your Arch Linux system configuration ([[rc.conf]]) so that the system clock will be correctly set on boot:<br />
<br />
HARDWARECLOCK="localtime"<br />
<br />
or<br />
<br />
HARDWARECLOCK="UTC"<br />
<br />
== Time Zone ==<br />
<br />
Be sure that your time zone is set correctly in {{ic|/etc/rc.conf}}. This is necessary not only for the localtime to be set correctly but also for other programs you may use. You can do this by:<br />
<br />
$ grep ^TIMEZONE /etc/rc.conf<br />
<br />
You can find the time zones listed in {{ic|/usr/share/zoneinfo/}} and then you will need to find a major city that exists to your time zone. If you live in a specialized time zone area these will be listed in sub-directories. An example configuration:<br />
<br />
TIMEZONE="America/Chicago"<br />
<br />
The new time zone will be taken into effect when you reboot. To change the timezone immediately you will need to link or copy it to {{ic|/etc/localtime}}:<br />
<br />
# cp /usr/share/zoneinfo/America/Chicago /etc/localtime<br />
<br />
When you [[#Time Set|set the hardware clock]] the new time zone will be take used.<br />
<br />
== Time Set ==<br />
<br />
The hardware clock can be set either directly or from the system clock. To check the current hardware clock time and system clock time respectively (the hardware clock time is presented in localtime even if the hardware clock set to UTC):<br />
<br />
# hwclock --show<br />
$ date<br />
<br />
To set the hardware clock directly (the argument must be in local time, even if you keep your hardware clock in UTC.):<br />
<br />
# hwclock --set --date="YYYY-MM-DD hh:mm:ss"<br />
<br />
To set the system clock:<br />
<br />
# date MMDDhhmmYYYY<br />
<br />
The hardware clock can be set from the system clock and vice versa:<br />
<br />
# hwclock --systohc<br />
# hwclock --hctosys<br />
<br />
== Time Skew ==<br />
<br />
Every clock has a value that differs from ''real time'' (the best representation of which being [[Wikipedia:International Atomic Time|International Atomic Time]]), no clock is perfect. A quartz based electronic clock keeps imperfect time, but maintains a consistent inaccuracy. This base 'inaccuracy' is known as 'time skew' or 'time drift'. When the hardware clock is set with {{ic|hwclock}}, a new drift value is calculated in seconds per day. The drift value is calculated by using the difference between the new value set and the hardware clock value just before the set, taking into account the value of the previous drift value and the last time time the hardware clock was set. The new drift value and the time when the clock was set is written to the file {{ic|/var/lib/hwclock/adjtime}} overwriting the previous values.<br />
<br />
{{Note|If the hwclock has been set again less than 24 hours after a previous set, the drift is not recalculated as {{ic|hwclock}} considers the elaspsed time period too short to accurately calculate the drift.}}<br />
<br />
If the hardware clock keeps losing or gaining time in large increments, it is possible that an invalid drift has been recorded. This can happen if you have set the hardware clock time incorrectly or your [[#Time Standard|time standard]] is not synchronized with a Windows or Mac OS install. The drift value can be removed by removing the file {{ic|/var/lib/hwclock/adjtime}}, then set the correct hardware clock and system clock time, and check if your [[#Time Standard|time standard]] is correct.<br />
<br />
The system clock is calculated by the Linux kernel as the number of seconds since midnight January 1st 1970 UTC. The initial value of the system clock is calculated from the hardware clock, dependent on the value of the HARDWARECLOCK defined in {{ic|/etc/rc.conf}}. Once power up has completed the system clock runs independently of the hardware clock. The Linux kernel keeps track of the system clock by counting timer interrupts. The software clock is very accurate but like most clocks is not perfectly accurate and will drift as well. Though rarely, the system clock can lose accuracy if the kernel skips interrupts. System clocks can be kept on accurate time by using [[NTP]]. NTP can also will adjust the interrupt frequency and the number of ticks per second to decrease system clock drift.<br />
<br />
== UTC in Windows ==<br />
<br />
Add the DWORD value:<br />
<br />
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\TimeZoneInformation\RealTimeIsUniversal<br />
<br />
with hexadecimal value 1 to the registry (through regedit). Windows XP and Windows Vista SP1 have support for setting the time standard as {{ic|UTC}} and can be activated in the same way however there is a bug after resuming from the suspend/hibernation state that resets the clock to {{ic|localtime}}. For these operating systems it is recommended to use {{ic|localtime}}.<br />
<br />
The hardware clock and system clock time may need to be [[#Setting the time|updated]] after setting this value.<br />
<br />
== Other Details ==<br />
<br />
* 32-bit Linux systems will stop working in 2038. Since system time is recorded as a 32-bit integer (the number of seconds since 1970-01-01) it's limitation will extend only this long.<br />
* If you regularly shutdown/reboot your computer numerous times in a day the recorded drift value will never get calculated, it may be worth occasionally to stay in Linux so it gets calculated.<br />
* The [[Arch User Repository|AUR]] package {{AUR|adjtimex}} can adjust kernel time variables like interupt frequency to help improve the system clock time drift.<br />
* During kernel startup, at the point when the rtc driver is loaded, the system clock may be set from the hardware clock. Whether this occurs or not depends on the hardware platform, the version of the kernel and kernel build options. If this does occur, at this point in the boot sequence, the hardware clock time is assumed to be UTC and the value of {{ic|/proc/sys/class/rtcN/hctosys}} (N=0,1,2,..) will be set to 1. Later during execution of {{ic|/etc/rc.sysinit}}, the system clock is set again from the hardware clock dependent on the value of HARDWARECLOCK. Hence, having the hardware clock using localtime may cause some unexpected behaviour during the boot sequence; e.g system time going backwards which is always a bad idea,<br />
* The hardware clock is adjusted for drift only when the command {{ic|hwclock --adjust}} is run. Currently this only occurs if the {{ic|hwclock}} daemon is enabled and then only during shutdown. <br />
* Running the {{ic|hwclock}} daemon is not recommended if running the {{AUR|NTP}} daemon as the {{AUR|NTP}} daemon also adjusts the hardware clock.<br />
<br />
== It's About 'Time' == <br />
<!-- This was the introduction to the original 'Time' article by [[User:Android]]; kept for nostalgia's sake. --><br />
<br />
Our concept of time speaks much more to our limited perception than it does to the nature of what we observe. Time is clearly the most fertile ground for a fundamental shift in the human conception of the objective natural universe.<br />
<br />
Time has been measured since the beginning of time, at least as a human concept. The most obvious natural marker of the passage of time is the progression of day and night. The "day" was the first known measure of time and still forms a fundamental part of timekeeping. Other cyclic natural phenomena are also historically associated with time; the word "tide" comes from a common etymological root. Even with computer timekeeping, the day is a fundamental concept.<br />
<br />
As the measurement of time has improved, standard measures of time have had to be revised. The "leapyear" accounts for the fact that the Earth's orbit around the sun is not exactly 365 days. With the advent of atomic clocks in the 1960s, it became clear that the Earth's daily rotation was gradually slowing down (primarily due to tidal friction). The definition of the second in terms of cesium atom oscillations is the basis of the time standard known as [[Wikipedia:International Atomic Time|'''I'''nternational '''A'''tomic '''T'''ime]], or '''TAI'''.<br />
<br />
The slow and irregular increase in the amount of time comprising a day occasionally causes problems with the POSIX definition of a day as 86400 seconds. This led to the introduction of the "leapsecond" in 1972. Occasionally a second must be inserted into the normally defined UTC sequence in order to keep it synchronized with TAI.<br />
<br />
== Resources ==<br />
<br />
* [http://www.linuxsa.org.au/tips/time.html Linux Tips - Linux, Clocks, and Time]<br />
* [http://www.twinsun.com/tz/tz-link.htm Sources for Time Zone and Daylight Saving Time Data] for {{Pkg|tzdata}}<br />
* [http://www.ucolick.org/~sla/leapsecs/timescales.html Time Scales]<br />
* [[Wikipedia:Time]]</div>PeterLhttps://wiki.archlinux.org/index.php?title=System_time&diff=174778System time2011-12-17T20:03:13Z<p>PeterL: hwclock daemon should not be used when running ntpd, so comment about hwclock daemon removed.</p>
<hr />
<div>[[Category:Mainboards and BIOS (English)]] <!-- with regard to the hardware clock --><br />
[[Category:Daemons and system services (English)]] <!-- as the basis/rationale for NTP --><br />
{{i18n|Time}}<br />
{{Article summary start}}<br />
{{Article summary text|This article provides an introduction to the concept of keeping time on computers in general, and describes how clocks are configured and managed in Arch Linux.}}<br />
{{Article summary heading|Related}}<br />
{{Article summary wiki|Network Time Protocol}}<br />
{{Article summary wiki|rc.conf}}<br />
{{Article summary end}}<br />
<br />
This article explains how the time is read and set. The hardware clock (a.k.a. the Real Time Clock (RTC) or CMOS clock) and the system clock need to be set up correctly to maintain proper time. For ''maintaining'' accurate system time see [[Network Time Protocol]].<br />
<br />
== About ==<br />
<br />
The hardware clock stores the values of: Year, Month, Day, Hour, Minute, and the Seconds. The hardware clock time value will be of either of two standards: either the '''localtime''' standard, or the '''C'''oordinated '''U'''niversal '''T'''ime ('''UTC''') standard (also known as GMT, though conceptually different). The localtime standard is dependent on the current ''time zone'', while UTC is the ''global'' time standard and is independent of time zone values. The hardware clock can only store time values and does not have the ability to store the time standard (localtime or UTC), nor whether '''D'''aylight '''S'''aving '''T'''ime ('''DST''') is used.<br />
<br />
The hardware clock time standard (localtime or UTC) can be defined to most operating system's system clocks. By default, Windows uses localtime, Mac OS uses UTC, and UNIX-like operating systems vary. The system clock (a.k.a. the software clock) runs independent of the hardware clock and keeps track of: Time, Time Zone, and DST if applicable. Standard behavior of most operating systems is to set the system clock from the hardware clock on boot, keep accurate time of the system clock with an [[Network Time Protocol daemon|NTP]] daemon. When [[Network Time Protocol daemon|NTP]] daemon is running the hardware clock is periodically updated from system clock. <br />
<br />
When using Linux it is beneficial to have the hardware clock set to the UTC standard and made known to all operating systems. Defining the hardware clock in Linux as UTC means that Daylight Savings Time will automatically be accounted for. If using the localtime standard the system clock will not be changed for DST occurances assuming that another operating system will take care of the DST switch (and provided no NTP agent is operating).<br />
<br />
== Time Standard ==<br />
<br />
You can set the hardware clock time standard through the command line. You can check what you have set your Arch Linux install to use by:<br />
<br />
$ grep ^HARDWARECLOCK /etc/rc.conf<br />
<br />
The hardware clock can be queried and set with the {{ic|hwclock}} command. To immediately change the hardware clock time standard to localtime use:<br />
<br />
# hwclock --localtime<br />
<br />
And to set it to UTC use:<br />
<br />
# hwclock --utc<br />
<br />
The time standard that the hardware clock uses will also need to be entered in your Arch Linux system configuration ([[rc.conf]]) so that the system clock will be correctly set on boot:<br />
<br />
HARDWARECLOCK="localtime"<br />
<br />
or<br />
<br />
HARDWARECLOCK="UTC"<br />
<br />
== Time Zone ==<br />
<br />
Be sure that your time zone is set correctly in {{ic|/etc/rc.conf}}. This is necessary not only for the localtime to be set correctly but also for other programs you may use. You can do this by:<br />
<br />
$ grep ^TIMEZONE /etc/rc.conf<br />
<br />
You can find the time zones listed in {{ic|/usr/share/zoneinfo/}} and then you will need to find a major city that exists to your time zone. If you live in a specialized time zone area these will be listed in sub-directories. An example configuration:<br />
<br />
TIMEZONE="America/Chicago"<br />
<br />
The new time zone will be taken into effect when you reboot. To change the timezone immediately you will need to link or copy it to {{ic|/etc/localtime}}:<br />
<br />
# cp /usr/share/zoneinfo/America/Chicago /etc/localtime<br />
<br />
When you [[#Time Set|set the hardware clock]] the new time zone will be take used.<br />
<br />
== Time Set ==<br />
<br />
The hardware clock can be set either directly or from the system clock. To check the current hardware clock time and system clock time respectively (the hardware clock time is presented in localtime even if the hardware clock set to UTC):<br />
<br />
# hwclock --show<br />
$ date<br />
<br />
To set the hardware clock directly (the argument must be in local time, even if you keep your hardware clock in UTC.):<br />
<br />
# hwclock --set --date="YYYY-MM-DD hh:mm:ss"<br />
<br />
To set the system clock:<br />
<br />
# date MMDDhhmmYYYY<br />
<br />
The hardware clock can be set from the system clock and vice versa:<br />
<br />
# hwclock --systohc<br />
# hwclock --hctosys<br />
<br />
== Time Skew ==<br />
<br />
Every clock has a value that differs from ''real time'' (the best representation of which being [[Wikipedia:International Atomic Time|International Atomic Time]]), no clock is perfect. A quartz based electronic clock keeps imperfect time, but maintains a consistent inaccuracy. This base 'inaccuracy' is known as 'time skew' or 'time drift'. When the hardware clock is set with {{ic|hwclock}}, a new drift value is calculated in seconds per day. The drift value is calculated by using the difference between the new value set and the hardware clock value just before the set, taking into account the value of the previous drift value and the last time time the hardware clock was set. The new drift value and the time when the clock was set is written to the file {{ic|/var/lib/hwclock/adjtime}} overwriting the previous values.<br />
<br />
{{Note|If the hwclock has been set again less than 24 hours after a previous set, the drift is not recalculated as {{ic|hwclock}} considers the elaspsed time period too short to accurately calculate the drift.}}<br />
<br />
If the hardware clock keeps losing or gaining time in large increments, it is possible that an invalid drift has been recorded. This can happen if you have set the hardware clock time incorrectly or your [[#Time Standard|time standard]] is not synchronized with a Windows or Mac OS install. The drift value can be removed by removing the file {{ic|/var/lib/hwclock/adjtime}}, then set the correct hardware clock and system clock time, and check if your [[#Time Standard|time standard]] is correct.<br />
<br />
The system clock is calculated by the Linux kernel as the number of seconds since midnight January 1st 1970 UTC. The initial value of the system clock is calculated from the hardware clock, dependent on the value of the HARDWARECLOCK defined in {{ic|/etc/rc.conf}}. Once power up has completed the system clock runs independently of the hardware clock. The Linux kernel keeps track of the system clock by counting timer interrupts. The software clock is very accurate but like most clocks is not perfectly accurate and will drift as well. Though rarely, the system clock can lose accuracy if the kernel skips interrupts. System clocks can be kept on accurate time by using [[NTP]]. NTP can also will adjust the interrupt frequency and the number of ticks per second to decrease system clock drift.<br />
<br />
== UTC in Windows ==<br />
<br />
Add the DWORD value:<br />
<br />
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\TimeZoneInformation\RealTimeIsUniversal<br />
<br />
with hexadecimal value 1 to the registry (through regedit). Windows XP and Windows Vista SP1 have support for setting the time standard as {{ic|UTC}} and can be activated in the same way however there is a bug after resuming from the suspend/hibernation state that resets the clock to {{ic|localtime}}. For these operating systems it is recommended to use {{ic|localtime}}.<br />
<br />
The hardware clock and system clock time may need to be [[#Setting the time|updated]] after setting this value.<br />
<br />
== Other Details ==<br />
<br />
* 32-bit Linux systems will stop working in 2038. Since system time is recorded as a 32-bit integer (the number of seconds since 1970-01-01) it's limitation will extend only this long.<br />
* If you regularly shutdown/reboot your computer numerous times in a day the recorded drift value will never get calculated, it may be worth occasionally to stay in Linux so it gets calculated.<br />
* The [[Arch User Repository|AUR]] package {{AUR|adjtimex}} can adjust kernel time variables like interupt frequency to help improve the system clock time drift.<br />
* During kernel startup, at the point when the rtc driver is loaded, the system clock may or may not be set from the hardware clock. Whether this occurs or not depends on the hardware platform, the version of the kernel and kernel build options. If this does occur, at this point in the boot sequence, the hardware clock time is assumed to be UTC and the value of {{ic|/proc/sys/class/rtcN/hctosys}} (N=0,1,2,..) will be set to 1. Later during execution of {{ic|/etc/rc.sysinit}}, the system clock is set again from the hardware clock dependent on the value of HARDWARECLOCK. Hence, setting hwclock to localtime may cause some unexpected behaviour during the boot sequence.<br />
<br />
== It's About 'Time' == <br />
<!-- This was the introduction to the original 'Time' article by [[User:Android]]; kept for nostalgia's sake. --><br />
<br />
Our concept of time speaks much more to our limited perception than it does to the nature of what we observe. Time is clearly the most fertile ground for a fundamental shift in the human conception of the objective natural universe.<br />
<br />
Time has been measured since the beginning of time, at least as a human concept. The most obvious natural marker of the passage of time is the progression of day and night. The "day" was the first known measure of time and still forms a fundamental part of timekeeping. Other cyclic natural phenomena are also historically associated with time; the word "tide" comes from a common etymological root. Even with computer timekeeping, the day is a fundamental concept.<br />
<br />
As the measurement of time has improved, standard measures of time have had to be revised. The "leapyear" accounts for the fact that the Earth's orbit around the sun is not exactly 365 days. With the advent of atomic clocks in the 1960s, it became clear that the Earth's daily rotation was gradually slowing down (primarily due to tidal friction). The definition of the second in terms of cesium atom oscillations is the basis of the time standard known as [[Wikipedia:International Atomic Time|'''I'''nternational '''A'''tomic '''T'''ime]], or '''TAI'''.<br />
<br />
The slow and irregular increase in the amount of time comprising a day occasionally causes problems with the POSIX definition of a day as 86400 seconds. This led to the introduction of the "leapsecond" in 1972. Occasionally a second must be inserted into the normally defined UTC sequence in order to keep it synchronized with TAI.<br />
<br />
== Resources ==<br />
<br />
* [http://www.linuxsa.org.au/tips/time.html Linux Tips - Linux, Clocks, and Time]<br />
* [http://www.twinsun.com/tz/tz-link.htm Sources for Time Zone and Daylight Saving Time Data] for {{Pkg|tzdata}}<br />
* [http://www.ucolick.org/~sla/leapsecs/timescales.html Time Scales]<br />
* [[Wikipedia:Time]]</div>PeterLhttps://wiki.archlinux.org/index.php?title=System_time&diff=174035System time2011-12-13T20:53:40Z<p>PeterL: spelling correction</p>
<hr />
<div>[[Category:Mainboards and BIOS (English)]] <!-- with regard to the hardware clock --><br />
[[Category:Daemons and system services (English)]] <!-- as the basis/rationale for NTP --><br />
{{i18n|Time}}<br />
{{Article summary start}}<br />
{{Article summary text|This article provides an introduction to the concept of keeping time on computers in general, and describes how clocks are configured and managed in Arch Linux.}}<br />
{{Article summary heading|Related}}<br />
{{Article summary wiki|Network Time Protocol}}<br />
{{Article summary wiki|rc.conf}}<br />
{{Article summary end}}<br />
<br />
This article explains how the time is read and set. The hardware clock (a.k.a. the Real Time Clock (RTC) or CMOS clock) and the system clock need to be set up correctly to maintain proper time. For ''maintaining'' accurate system time see [[Network Time Protocol]].<br />
<br />
== About ==<br />
<br />
The hardware clock stores the values of: Year, Month, Day, Hour, Minute, and the Seconds. The hardware clock time value will be of either of two standards: either the '''localtime''' standard, or the '''C'''oordinated '''U'''niversal '''T'''ime ('''UTC''') standard (also known as GMT, though conceptually different). The localtime standard is dependent on the current ''time zone'', while UTC is the ''global'' time standard and is independent of time zone values. The hardware clock can only store time values and does not have the ability to store the time standard (localtime or UTC), nor whether '''D'''aylight '''S'''aving '''T'''ime ('''DST''') is used.<br />
<br />
The hardware clock time standard (localtime or UTC) can be defined to most operating system's system clocks. By default, Windows uses localtime, Mac OS uses UTC, and UNIX-like operating systems vary. The system clock (a.k.a. the software clock) runs independent of the hardware clock and keeps track of: Time, Time Zone, and DST if applicable. Standard behavior of most operating systems is to set the system clock from the hardware clock on boot, keep accurate time of the system clock with an [[NTP]] program, and set the hardware clock from the system clock on shutdown. In Arch Linux, the daemon {{ic|/etc/rc.d/hwclock}} uses {{ic|hwclock}} to set the system and hardware clocks on boot and shutdown if 'hwclock' is in the DAEMONS list in {{ic|/etc/rc.conf}}).<br />
<br />
When using Linux it is beneficial to have the hardware clock set to the UTC standard and made known to all operating systems. Defining the hardware clock in Linux as UTC means that Daylight Savings Time will automatically be accounted for. If using the localtime standard the system clock will not be changed for DST occurances assuming that another operating system will take care of the DST switch (and provided no NTP agent is operating). <br />
<br />
== Time Standard ==<br />
<br />
You can set the hardware clock time standard through the command line. You can check what you have set your Arch Linux install to use by:<br />
<br />
$ grep ^HARDWARECLOCK /etc/rc.conf<br />
<br />
The hardware clock can be queried and set with the {{ic|hwclock}} command. To immediately change the hardware clock time standard to localtime use:<br />
<br />
# hwclock --localtime<br />
<br />
And to set it to UTC use:<br />
<br />
# hwclock --utc<br />
<br />
The time standard that the hardware clock uses will also need to be entered in your Arch Linux system configuration ([[rc.conf]]) so that the system clock will be correctly set on boot:<br />
<br />
HARDWARECLOCK="localtime"<br />
<br />
or<br />
<br />
HARDWARECLOCK="UTC"<br />
<br />
== Time Zone ==<br />
<br />
Be sure that your time zone is set correctly in {{ic|/etc/rc.conf}}. This is necessary not only for the localtime to be set correctly but also for other programs you may use. You can do this by:<br />
<br />
$ grep ^TIMEZONE /etc/rc.conf<br />
<br />
You can find the time zones listed in {{ic|/usr/share/zoneinfo/}} and then you will need to find a major city that exists to your time zone. If you live in a specialized time zone area these will be listed in sub-directories. An example configuration:<br />
<br />
TIMEZONE="America/Chicago"<br />
<br />
The new time zone will be taken into effect when you reboot. To change the timezone immediately you will need to link or copy it to {{ic|/etc/localtime}}:<br />
<br />
# cp /usr/share/zoneinfo/America/Chicago /etc/localtime<br />
<br />
When you [[#Time Set|set the hardware clock]] the new time zone will be take used.<br />
<br />
== Time Set ==<br />
<br />
The hardware clock can be set either directly or from the system clock. To check the current hardware clock time and system clock time respectively (the hardware clock time is presented in localtime even if the hardware clock set to UTC):<br />
<br />
# hwclock --show<br />
$ date<br />
<br />
To set the hardware clock directly (the argument must be in local time, even if you keep your hardware clock in UTC.):<br />
<br />
# hwclock --set --date="YYYY-MM-DD hh:mm:ss"<br />
<br />
To set the system clock:<br />
<br />
# date MMDDhhmmYYYY<br />
<br />
The hardware clock can be set from the system clock and vice versa:<br />
<br />
# hwclock --systohc<br />
# hwclock --hctosys<br />
<br />
== Time Skew ==<br />
<br />
Every clock has a value that differs from ''real time'' (the best representation of which being [[Wikipedia:International Atomic Time|International Atomic Time]]), no clock is perfect. A quartz based electronic clock keeps imperfect time, but maintains a consistent inaccuracy. This base 'inaccuracy' is known as 'time skew' or 'time drift'. When the hardware clock is set with {{ic|hwclock}}, a new drift value is calculated in seconds per day. The drift value is calculated by using the difference between the new value set and the hardware clock value just before the set, taking into account the value of the previous drift value and the last time time the hardware clock was set. The new drift value and the time when the clock was set is written to the file {{ic|/var/lib/hwclock/adjtime}} overwriting the previous values.<br />
<br />
{{Note|If the hwclock has been set again less than 24 hours after a previous set, the drift is not recalculated as {{ic|hwclock}} considers the elaspsed time period too short to accurately calculate the drift.}}<br />
<br />
If the hardware clock keeps losing or gaining time in large increments, it is possible that an invalid drift has been recorded. This can happen if you have set the hardware clock time incorrectly or your [[#Time Standard|time standard]] is not synchronized with a Windows or Mac OS install. The drift value can be removed by removing the file {{ic|/var/lib/hwclock/adjtime}}, then set the correct hardware clock and system clock time, and check if your [[#Time Standard|time standard]] is correct.<br />
<br />
The system clock is calculated by the Linux kernel as the number of seconds since midnight January 1st 1970 UTC. The initial value of the system clock is calculated from the hardware clock, dependent on the value of the HARDWARECLOCK defined in {{ic|/etc/rc.conf}}. Once power up has completed the system clock runs independently of the hardware clock. The Linux kernel keeps track of the system clock by counting timer interrupts. The software clock is very accurate but like most clocks is not perfectly accurate and will drift as well. Though rarely, the system clock can lose accuracy if the kernel skips interrupts. System clocks can be kept on accurate time by using [[NTP]]. NTP can also will adjust the interrupt frequency and the number of ticks per second to decrease system clock drift.<br />
<br />
== UTC in Windows ==<br />
<br />
Add the DWORD value:<br />
<br />
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\TimeZoneInformation\RealTimeIsUniversal<br />
<br />
with hexadecimal value 1 to the registry (through regedit). Windows XP and Windows Vista SP1 have support for setting the time standard as {{ic|UTC}} and can be activated in the same way however there is a bug after resuming from the suspend/hibernation state that resets the clock to {{ic|localtime}}. For these operating systems it is recommended to use {{ic|localtime}}.<br />
<br />
The hardware clock and system clock time may need to be [[#Setting the time|updated]] after setting this value.<br />
<br />
== Other Details ==<br />
<br />
* 32-bit Linux systems will stop working in 2038. Since system time is recorded as a 32-bit integer (the number of seconds since 1970 01 01) it's limitation will extend only this long.<br />
* If you regularly shutdown/reboot your computer numerous times in a day the recorded drift value will never get calculated, it may be worth occasionally to stay in Linux so it gets calculated.<br />
* The AUR application {{ic|adjtimex}} can adjust kernel time variables like interupt frequency to help improve the system clock time drift.<br />
* During kernel startup, at the point when the rtc driver is loaded, the system clock may or may not be set from the hardware clock. Whether this occurs or not depends on the hardware platform, the version of the kernel and kernel build options. If this does occur, at this point in the boot sequence, the hardware clock time is assumed to be UTC and the value of {{ic|/proc/sys/class/rtcN/hctosys}} (N=0,1,2,..) will be set to 1. Later during execution of rc.sysinit, the system clock is set again from the hardware clock dependent on the value of HARDWARECLOCK. Hence, setting hwclock to localtime may cause some unexpected behaviour during the boot sequence.<br />
<br />
== It's About 'Time' == <br />
<!-- This was the introduction to the original 'Time' article by [[User:Android]]; kept for nostalgia's sake. --><br />
<br />
Our concept of time speaks much more to our limited perception than it does to the nature of what we observe. Time is clearly the most fertile ground for a fundamental shift in the human conception of the objective natural universe.<br />
<br />
Time has been measured since the beginning of time, at least as a human concept. The most obvious natural marker of the passage of time is the progression of day and night. The "day" was the first known measure of time and still forms a fundamental part of timekeeping. Other cyclic natural phenomena are also historically associated with time; the word "tide" comes from a common etymological root. Even with computer timekeeping, the day is a fundamental concept.<br />
<br />
As the measurement of time has improved, standard measures of time have had to be revised. The "leapyear" accounts for the fact that the Earth's orbit around the sun is not exactly 365 days. With the advent of atomic clocks in the 1960s, it became clear that the Earth's daily rotation was gradually slowing down (primarily due to tidal friction). The definition of the second in terms of cesium atom oscillations is the basis of the time standard known as [[Wikipedia:International Atomic Time|'''I'''nternational '''A'''tomic '''T'''ime]], or '''TAI'''.<br />
<br />
The slow and irregular increase in the amount of time comprising a day occasionally causes problems with the POSIX definition of a day as 86400 seconds. This lead to the introduction of the "leapsecond" in 1972. Occasionally a second must be inserted into the normally defined UTC sequence in order to keep it synchronized with TAI.<br />
<br />
== Resources ==<br />
<br />
* [http://www.linuxsa.org.au/tips/time.html Linux Tips - Linux, Clocks, and Time]<br />
* [http://www.twinsun.com/tz/tz-link.htm Sources for Time Zone and Daylight Saving Time Data] for {{Pkg|tzdata}}<br />
* [http://www.ucolick.org/~sla/leapsecs/timescales.html Time Scales]<br />
* [[Wikipedia:Time]]</div>PeterLhttps://wiki.archlinux.org/index.php?title=System_time&diff=174034System time2011-12-13T20:11:00Z<p>PeterL: I must check preview before pressing save.</p>
<hr />
<div>[[Category:Mainboards and BIOS (English)]] <!-- with regard to the hardware clock --><br />
[[Category:Daemons and system services (English)]] <!-- as the basis/rationale for NTP --><br />
{{i18n|Time}}<br />
{{Article summary start}}<br />
{{Article summary text|This article provides an introduction to the concept of keeping time on computers in general, and describes how clocks are configured and managed in Arch Linux.}}<br />
{{Article summary heading|Related}}<br />
{{Article summary wiki|Network Time Protocol}}<br />
{{Article summary wiki|rc.conf}}<br />
{{Article summary end}}<br />
<br />
This article explains how the time is read and set. The hardware clock (a.k.a. the Real Time Clock (RTC) or CMOS clock) and the system clock need to be set up correctly to maintain proper time. For ''maintaining'' accurate system time see [[Network Time Protocol]].<br />
<br />
== About ==<br />
<br />
The hardware clock stores the values of: Year, Month, Day, Hour, Minute, and the Seconds. The hardware clock time value will be of either of two standards: either the '''localtime''' standard, or the '''C'''oordinated '''U'''niversal '''T'''ime ('''UTC''') standard (also known as GMT, though conceptually different). The localtime standard is dependent on the current ''time zone'', while UTC is the ''global'' time standard and is independent of time zone values. The hardware clock can only store time values and does not have the ability to store the time standard (localtime or UTC), nor whether '''D'''aylight '''S'''aving '''T'''ime ('''DST''') is used.<br />
<br />
The hardware clock time standard (localtime or UTC) can be defined to most operating system's system clocks. By default, Windows uses localtime, Mac OS uses UTC, and UNIX-like operating systems vary. The system clock (a.k.a. the software clock) runs independent of the hardware clock and keeps track of: Time, Time Zone, and DST if applicable. Standard behavior of most operating systems is to set the system clock from the hardware clock on boot, keep accurate time of the system clock with an [[NTP]] program, and set the hardware clock from the system clock on shutdown. In Arch Linux, the daemon {{ic|/etc/rc.d/hwclock}} uses {{ic|hwclock}} to set the system and hardware clocks on boot and shutdown if 'hwclock' is in the DAEMONS list in {{ic|/etc/rc.conf}}).<br />
<br />
When using Linux it is beneficial to have the hardware clock set to the UTC standard and made known to all operating systems. Defining the hardware clock in Linux as UTC means that Daylight Savings Time will automatically be accounted for. If using the localtime standard the system clock will not be changed for DST occurances assuming that another operating system will take care of the DST switch (and provided no NTP agent is operating). <br />
<br />
== Time Standard ==<br />
<br />
You can set the hardware clock time standard through the command line. You can check what you have set your Arch Linux install to use by:<br />
<br />
$ grep ^HARDWARECLOCK /etc/rc.conf<br />
<br />
The hardware clock can be queried and set with the {{ic|hwclock}} command. To immediately change the hardware clock time standard to localtime use:<br />
<br />
# hwclock --localtime<br />
<br />
And to set it to UTC use:<br />
<br />
# hwclock --utc<br />
<br />
The time standard that the hardware clock uses will also need to be entered in your Arch Linux system configuration ([[rc.conf]]) so that the system clock will be correctly set on boot:<br />
<br />
HARDWARECLOCK="localtime"<br />
<br />
or<br />
<br />
HARDWARECLOCK="UTC"<br />
<br />
== Time Zone ==<br />
<br />
Be sure that your time zone is set correctly in {{ic|/etc/rc.conf}}. This is necessary not only for the localtime to be set correctly but also for other programs you may use. You can do this by:<br />
<br />
$ grep ^TIMEZONE /etc/rc.conf<br />
<br />
You can find the time zones listed in {{ic|/usr/share/zoneinfo/}} and then you will need to find a major city that exists to your time zone. If you live in a specialized time zone area these will be listed in sub-directories. An example configuration:<br />
<br />
TIMEZONE="America/Chicago"<br />
<br />
The new time zone will be taken into effect when you reboot. To change the timezone immediately you will need to link or copy it to {{ic|/etc/localtime}}:<br />
<br />
# cp /usr/share/zoneinfo/America/Chicago /etc/localtime<br />
<br />
When you [[#Time Set|set the hardware clock]] the new time zone will be take used.<br />
<br />
== Time Set ==<br />
<br />
The hardware clock can be set either directly or from the system clock. To check the current hardware clock time and system clock time respectively (the hardware clock time is presented in localtime even if the hardware clock set to UTC):<br />
<br />
# hwclock --show<br />
$ date<br />
<br />
To set the hardware clock directly (the argument must be in local time, even if you keep your hardware clock in UTC.):<br />
<br />
# hwclock --set --date="YYYY-MM-DD hh:mm:ss"<br />
<br />
To set the system clock:<br />
<br />
# date MMDDhhmmYYYY<br />
<br />
The hardware clock can be set from the system clock and vice versa:<br />
<br />
# hwclock --systohc<br />
# hwclock --hctosys<br />
<br />
== Time Skew ==<br />
<br />
Every clock has a value that differs from ''real time'' (the best representation of which being [[Wikipedia:International Atomic Time|International Atomic Time]]), no clock is perfect. A quartz based electronic clock keeps imperfect time, but maintains a consistent inaccuracy. This base 'inaccuracy' is known as 'time skew' or 'time drift'. When the hardware clock is set with {{ic|hwclock}}, a new drift value is calculated in seconds per day. The drift value is calculated by using the difference between the new value set and the hardware clock value just before the set, taking into account the value of the previous drift value and the last time time the hardware clock was set. The new drift value and the time when the clock was set is written to the file {{ic|/var/lib/hwclock/adjtime}} overwriting the previous values.<br />
<br />
{{Note|If the hwclock has been set again less than 24 hours after a previous set, the drift is not recalculated as {{ic|hwclock}} considers the elaspsed time period too short to accurately calculate the drift.}}<br />
<br />
If the hardware clock keeps losing or gaining time in large increments, it is possible that an invalid drift has been recorded. This can happen if you have set the hardware clock time incorrectly or your [[#Time Standard|time standard]] is not synchronized with a Windows or Mac OS install. The drift value can be removed by removing the file {{ic|/var/lib/hwclock/adjtime}}, then set the correct hardware clock and system clock time, and check if your [[#Time Standard|time standard]] is correct.<br />
<br />
The system clock is calculated by the Linux kernel as the number of seconds since midnight January 1st 1970 UTC. The initial value of the system clock is calculated from the hardware clock, dependent on the value of the HARDWARECLOCK defined in {{ic|/etc/rc.conf}}. Once power up has completed the system clock runs independently of the hardware clock. The Linux kernel keeps track of the system clock by counting timer interrupts. The software clock is very accurate but like most clocks is not perfectly accurate and will drift as well. Though rarely, the system clock can lose accuracy if the kernel skips interrupts. System clocks can be kept on accurate time by using [[NTP]]. NTP can also will adjust the interrupt frequency and the number of ticks per second to decrease system clock drift.<br />
<br />
== UTC in Windows ==<br />
<br />
Add the DWORD value:<br />
<br />
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\TimeZoneInformation\RealTimeIsUniversal<br />
<br />
with hexadecimal value 1 to the registry (through regedit). Windows XP and Windows Vista SP1 have support for setting the time standard as {{ic|UTC}} and can be activated in the same way however there is a bug after resuming from the suspend/hibernation state that resets the clock to {{ic|localtime}}. For these operating systems it is recommended to use {{ic|localtime}}.<br />
<br />
The hardware clock and system clock time may need to be [[#Setting the time|updated]] after setting this value.<br />
<br />
== Other Details ==<br />
<br />
* 32-bit Linux systems will stop working in 2038. Since system time is recorded as a 32-bit integer (the number of seconds since 1970 01 01) it's limitation will extend only this long.<br />
* If you regularly shutdown/reboot your computer numerous times in a day the recorded drift value will never get calculated, it may be worth occasionally to stay in Linux so it gets calculated.<br />
* The AUR application {{ic|adjtimex}} can adjust kernel time variables like interupt frequency to help improve the system clock time drift.<br />
* During kernel startup, at the point when the rtc driver is loaded, the system clock may or may not be set from the hardware clock. Whether this occurs or not depends on the hardware platform, the version of the kernel and kernel build options. If this does occur, at this point in the boot sequence, the hardware clock time is assumed to be UTC and the value of {{ic|/proc/sys/class/rtcN/hctosys}} (N=0,1,2,..) will be set to 1. Later during execution of rc.sysinit, the system clock is set again from the hardware clock dependent on the value of HARDWARECLOCK. Hence, setting hwclock to localtime may cause some unexpected behaviour duing the boot sequence.<br />
<br />
== It's About 'Time' == <br />
<!-- This was the introduction to the original 'Time' article by [[User:Android]]; kept for nostalgia's sake. --><br />
<br />
Our concept of time speaks much more to our limited perception than it does to the nature of what we observe. Time is clearly the most fertile ground for a fundamental shift in the human conception of the objective natural universe.<br />
<br />
Time has been measured since the beginning of time, at least as a human concept. The most obvious natural marker of the passage of time is the progression of day and night. The "day" was the first known measure of time and still forms a fundamental part of timekeeping. Other cyclic natural phenomena are also historically associated with time; the word "tide" comes from a common etymological root. Even with computer timekeeping, the day is a fundamental concept.<br />
<br />
As the measurement of time has improved, standard measures of time have had to be revised. The "leapyear" accounts for the fact that the Earth's orbit around the sun is not exactly 365 days. With the advent of atomic clocks in the 1960s, it became clear that the Earth's daily rotation was gradually slowing down (primarily due to tidal friction). The definition of the second in terms of cesium atom oscillations is the basis of the time standard known as [[Wikipedia:International Atomic Time|'''I'''nternational '''A'''tomic '''T'''ime]], or '''TAI'''.<br />
<br />
The slow and irregular increase in the amount of time comprising a day occasionally causes problems with the POSIX definition of a day as 86400 seconds. This lead to the introduction of the "leapsecond" in 1972. Occasionally a second must be inserted into the normally defined UTC sequence in order to keep it synchronized with TAI.<br />
<br />
== Resources ==<br />
<br />
* [http://www.linuxsa.org.au/tips/time.html Linux Tips - Linux, Clocks, and Time]<br />
* [http://www.twinsun.com/tz/tz-link.htm Sources for Time Zone and Daylight Saving Time Data] for {{Pkg|tzdata}}<br />
* [http://www.ucolick.org/~sla/leapsecs/timescales.html Time Scales]<br />
* [[Wikipedia:Time]]</div>PeterLhttps://wiki.archlinux.org/index.php?title=System_time&diff=174033System time2011-12-13T20:08:51Z<p>PeterL: One day I'll learn to spell correctly :-)</p>
<hr />
<div>[[Category:Mainboards and BIOS (English)]] <!-- with regard to the hardware clock --><br />
[[Category:Daemons and system services (English)]] <!-- as the basis/rationale for NTP --><br />
{{i18n|Time}}<br />
{{Article summary start}}<br />
{{Article summary text|This article provides an introduction to the concept of keeping time on computers in general, and describes how clocks are configured and managed in Arch Linux.}}<br />
{{Article summary heading|Related}}<br />
{{Article summary wiki|Network Time Protocol}}<br />
{{Article summary wiki|rc.conf}}<br />
{{Article summary end}}<br />
<br />
This article explains how the time is read and set. The hardware clock (a.k.a. the Real Time Clock (RTC) or CMOS clock) and the system clock need to be set up correctly to maintain proper time. For ''maintaining'' accurate system time see [[Network Time Protocol]].<br />
<br />
== About ==<br />
<br />
The hardware clock stores the values of: Year, Month, Day, Hour, Minute, and the Seconds. The hardware clock time value will be of either of two standards: either the '''localtime''' standard, or the '''C'''oordinated '''U'''niversal '''T'''ime ('''UTC''') standard (also known as GMT, though conceptually different). The localtime standard is dependent on the current ''time zone'', while UTC is the ''global'' time standard and is independent of time zone values. The hardware clock can only store time values and does not have the ability to store the time standard (localtime or UTC), nor whether '''D'''aylight '''S'''aving '''T'''ime ('''DST''') is used.<br />
<br />
The hardware clock time standard (localtime or UTC) can be defined to most operating system's system clocks. By default, Windows uses localtime, Mac OS uses UTC, and UNIX-like operating systems vary. The system clock (a.k.a. the software clock) runs independent of the hardware clock and keeps track of: Time, Time Zone, and DST if applicable. Standard behavior of most operating systems is to set the system clock from the hardware clock on boot, keep accurate time of the system clock with an [[NTP]] program, and set the hardware clock from the system clock on shutdown. In Arch Linux, the daemon {{ic|/etc/rc.d/hwclock}} uses {{ic|hwclock}} to set the system and hardware clocks on boot and shutdown if 'hwclock' is in the DAEMONS list in {{ic|/etc/rc.conf}}).<br />
<br />
When using Linux it is beneficial to have the hardware clock set to the UTC standard and made known to all operating systems. Defining the hardware clock in Linux as UTC means that Daylight Savings Time will automatically be accounted for. If using the localtime standard the system clock will not be changed for DST occurances assuming that another operating system will take care of the DST switch (and provided no NTP agent is operating). <br />
<br />
== Time Standard ==<br />
<br />
You can set the hardware clock time standard through the command line. You can check what you have set your Arch Linux install to use by:<br />
<br />
$ grep ^HARDWARECLOCK /etc/rc.conf<br />
<br />
The hardware clock can be queried and set with the {{ic|hwclock}} command. To immediately change the hardware clock time standard to localtime use:<br />
<br />
# hwclock --localtime<br />
<br />
And to set it to UTC use:<br />
<br />
# hwclock --utc<br />
<br />
The time standard that the hardware clock uses will also need to be entered in your Arch Linux system configuration ([[rc.conf]]) so that the system clock will be correctly set on boot:<br />
<br />
HARDWARECLOCK="localtime"<br />
<br />
or<br />
<br />
HARDWARECLOCK="UTC"<br />
<br />
== Time Zone ==<br />
<br />
Be sure that your time zone is set correctly in {{ic|/etc/rc.conf}}. This is necessary not only for the localtime to be set correctly but also for other programs you may use. You can do this by:<br />
<br />
$ grep ^TIMEZONE /etc/rc.conf<br />
<br />
You can find the time zones listed in {{ic|/usr/share/zoneinfo/}} and then you will need to find a major city that exists to your time zone. If you live in a specialized time zone area these will be listed in sub-directories. An example configuration:<br />
<br />
TIMEZONE="America/Chicago"<br />
<br />
The new time zone will be taken into effect when you reboot. To change the timezone immediately you will need to link or copy it to {{ic|/etc/localtime}}:<br />
<br />
# cp /usr/share/zoneinfo/America/Chicago /etc/localtime<br />
<br />
When you [[#Time Set|set the hardware clock]] the new time zone will be take used.<br />
<br />
== Time Set ==<br />
<br />
The hardware clock can be set either directly or from the system clock. To check the current hardware clock time and system clock time respectively (the hardware clock time is presented in localtime even if the hardware clock set to UTC):<br />
<br />
# hwclock --show<br />
$ date<br />
<br />
To set the hardware clock directly (the argument must be in local time, even if you keep your hardware clock in UTC.):<br />
<br />
# hwclock --set --date="YYYY-MM-DD hh:mm:ss"<br />
<br />
To set the system clock:<br />
<br />
# date MMDDhhmmYYYY<br />
<br />
The hardware clock can be set from the system clock and vice versa:<br />
<br />
# hwclock --systohc<br />
# hwclock --hctosys<br />
<br />
== Time Skew ==<br />
<br />
Every clock has a value that differs from ''real time'' (the best representation of which being [[Wikipedia:International Atomic Time|International Atomic Time]]), no clock is perfect. A quartz based electronic clock keeps imperfect time, but maintains a consistent inaccuracy. This base 'inaccuracy' is known as 'time skew' or 'time drift'. When the hardware clock is set with {{ic|hwclock}}, a new drift value is calculated in seconds per day. The drift value is calculated by using the difference between the new value set and the hardware clock value just before the set, taking into account the value of the previous drift value and the last time time the hardware clock was set. The new drift value and the time when the clock was set is written to the file {{ic|/var/lib/hwclock/adjtime}} overwriting the previous values.<br />
<br />
{{Note|If the hwclock has been set again less than 24 hours after a previous set, the drift is not recalculated as {{ic|hwclock}} considers the elaspsed time period too short to accurately calculate the drift.}}<br />
<br />
If the hardware clock keeps losing or gaining time in large increments, it is possible that an invalid drift has been recorded. This can happen if you have set the hardware clock time incorrectly or your [[#Time Standard|time standard]] is not synchronized with a Windows or Mac OS install. The drift value can be removed by removing the file {{ic|/var/lib/hwclock/adjtime}}, then set the correct hardware clock and system clock time, and check if your [[#Time Standard|time standard]] is correct.<br />
<br />
The system clock is calculated by the Linux kernel as the number of seconds since midnight January 1st 1970 UTC. The initial value of the system clock is calculated from the hardware clock, dependent on the value of the HARDWARECLOCK defined in {{ic|/etc/rc.conf}}. Once power up has completed the system clock runs independently of the hardware clock. The Linux kernel keeps track of the system clock by counting timer interrupts. The software clock is very accurate but like most clocks is not perfectly accurate and will drift as well. Though rarely, the system clock can lose accuracy if the kernel skips interrupts. System clocks can be kept on accurate time by using [[NTP]]. NTP can also will adjust the interrupt frequency and the number of ticks per second to decrease system clock drift.<br />
<br />
== UTC in Windows ==<br />
<br />
Add the DWORD value:<br />
<br />
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\TimeZoneInformation\RealTimeIsUniversal<br />
<br />
with hexadecimal value 1 to the registry (through regedit). Windows XP and Windows Vista SP1 have support for setting the time standard as {{ic|UTC}} and can be activated in the same way however there is a bug after resuming from the suspend/hibernation state that resets the clock to {{ic|localtime}}. For these operating systems it is recommended to use {{ic|localtime}}.<br />
<br />
The hardware clock and system clock time may need to be [[#Setting the time|updated]] after setting this value.<br />
<br />
== Other Details ==<br />
<br />
* 32-bit Linux systems will stop working in 2038. Since system time is recorded as a 32-bit integer (the number of seconds since 1970 01 01) it's limitation will extend only this long.<br />
* If you regularly shutdown/reboot your computer numerous times in a day the recorded drift value will never get calculated, it may be worth occasionally to stay in Linux so it gets calculated.<br />
* The AUR application {{ic|adjtimex}} can adjust kernel time variables like interupt frequency to help improve the system clock time drift.<br />
* During kernel startup, at the point when the rtc driver is loaded, the system clock may or may not be set from the hardware clock. Whether this occurs or not depends on the hardware platform, the version of the kernel and kernel build options. If this does occur, at this point in the boot sequence, the hardware clock time is assumed to be UTC and the value of {{ic|/proc/sys/class/rtcN/hctosys} (N=0,1,2,..) will be set to 1. Later during execution of rc.sysinit, the system clock is set again from the hardware clock dependent on the value of HARDWARECLOCK. Hence, setting hwclock to localtime may cause some unexpected behaviour duing the boot sequence.<br />
<br />
== It's About 'Time' == <br />
<!-- This was the introduction to the original 'Time' article by [[User:Android]]; kept for nostalgia's sake. --><br />
<br />
Our concept of time speaks much more to our limited perception than it does to the nature of what we observe. Time is clearly the most fertile ground for a fundamental shift in the human conception of the objective natural universe.<br />
<br />
Time has been measured since the beginning of time, at least as a human concept. The most obvious natural marker of the passage of time is the progression of day and night. The "day" was the first known measure of time and still forms a fundamental part of timekeeping. Other cyclic natural phenomena are also historically associated with time; the word "tide" comes from a common etymological root. Even with computer timekeeping, the day is a fundamental concept.<br />
<br />
As the measurement of time has improved, standard measures of time have had to be revised. The "leapyear" accounts for the fact that the Earth's orbit around the sun is not exactly 365 days. With the advent of atomic clocks in the 1960s, it became clear that the Earth's daily rotation was gradually slowing down (primarily due to tidal friction). The definition of the second in terms of cesium atom oscillations is the basis of the time standard known as [[Wikipedia:International Atomic Time|'''I'''nternational '''A'''tomic '''T'''ime]], or '''TAI'''.<br />
<br />
The slow and irregular increase in the amount of time comprising a day occasionally causes problems with the POSIX definition of a day as 86400 seconds. This lead to the introduction of the "leapsecond" in 1972. Occasionally a second must be inserted into the normally defined UTC sequence in order to keep it synchronized with TAI.<br />
<br />
== Resources ==<br />
<br />
* [http://www.linuxsa.org.au/tips/time.html Linux Tips - Linux, Clocks, and Time]<br />
* [http://www.twinsun.com/tz/tz-link.htm Sources for Time Zone and Daylight Saving Time Data] for {{Pkg|tzdata}}<br />
* [http://www.ucolick.org/~sla/leapsecs/timescales.html Time Scales]<br />
* [[Wikipedia:Time]]</div>PeterLhttps://wiki.archlinux.org/index.php?title=System_time&diff=174032System time2011-12-13T20:06:20Z<p>PeterL: /* Other Details */</p>
<hr />
<div>[[Category:Mainboards and BIOS (English)]] <!-- with regard to the hardware clock --><br />
[[Category:Daemons and system services (English)]] <!-- as the basis/rationale for NTP --><br />
{{i18n|Time}}<br />
{{Article summary start}}<br />
{{Article summary text|This article provides an introduction to the concept of keeping time on computers in general, and describes how clocks are configured and managed in Arch Linux.}}<br />
{{Article summary heading|Related}}<br />
{{Article summary wiki|Network Time Protocol}}<br />
{{Article summary wiki|rc.conf}}<br />
{{Article summary end}}<br />
<br />
This article explains how the time is read and set. The hardware clock (a.k.a. the Real Time Clock (RTC) or CMOS clock) and the system clock need to be set up correctly to maintain proper time. For ''maintaining'' accurate system time see [[Network Time Protocol]].<br />
<br />
== About ==<br />
<br />
The hardware clock stores the values of: Year, Month, Day, Hour, Minute, and the Seconds. The hardware clock time value will be of either of two standards: either the '''localtime''' standard, or the '''C'''oordinated '''U'''niversal '''T'''ime ('''UTC''') standard (also known as GMT, though conceptually different). The localtime standard is dependent on the current ''time zone'', while UTC is the ''global'' time standard and is independent of time zone values. The hardware clock can only store time values and does not have the ability to store the time standard (localtime or UTC), nor whether '''D'''aylight '''S'''aving '''T'''ime ('''DST''') is used.<br />
<br />
The hardware clock time standard (localtime or UTC) can be defined to most operating system's system clocks. By default, Windows uses localtime, Mac OS uses UTC, and UNIX-like operating systems vary. The system clock (a.k.a. the software clock) runs independent of the hardware clock and keeps track of: Time, Time Zone, and DST if applicable. Standard behavior of most operating systems is to set the system clock from the hardware clock on boot, keep accurate time of the system clock with an [[NTP]] program, and set the hardware clock from the system clock on shutdown. In Arch Linux, the daemon {{ic|/etc/rc.d/hwclock}} uses {{ic|hwclock}} to set the system and hardware clocks on boot and shutdown if 'hwclock' is in the DAEMONS list in {{ic|/etc/rc.conf}}).<br />
<br />
When using Linux it is beneficial to have the hardware clock set to the UTC standard and made known to all operating systems. Defining the hardware clock in Linux as UTC means that Daylight Savings Time will automatically be accounted for. If using the localtime standard the system clock will not be changed for DST occurances assuming that another operating system will take care of the DST switch (and provided no NTP agent is operating). <br />
<br />
== Time Standard ==<br />
<br />
You can set the hardware clock time standard through the command line. You can check what you have set your Arch Linux install to use by:<br />
<br />
$ grep ^HARDWARECLOCK /etc/rc.conf<br />
<br />
The hardware clock can be queried and set with the {{ic|hwclock}} command. To immediately change the hardware clock time standard to localtime use:<br />
<br />
# hwclock --localtime<br />
<br />
And to set it to UTC use:<br />
<br />
# hwclock --utc<br />
<br />
The time standard that the hardware clock uses will also need to be entered in your Arch Linux system configuration ([[rc.conf]]) so that the system clock will be correctly set on boot:<br />
<br />
HARDWARECLOCK="localtime"<br />
<br />
or<br />
<br />
HARDWARECLOCK="UTC"<br />
<br />
== Time Zone ==<br />
<br />
Be sure that your time zone is set correctly in {{ic|/etc/rc.conf}}. This is necessary not only for the localtime to be set correctly but also for other programs you may use. You can do this by:<br />
<br />
$ grep ^TIMEZONE /etc/rc.conf<br />
<br />
You can find the time zones listed in {{ic|/usr/share/zoneinfo/}} and then you will need to find a major city that exists to your time zone. If you live in a specialized time zone area these will be listed in sub-directories. An example configuration:<br />
<br />
TIMEZONE="America/Chicago"<br />
<br />
The new time zone will be taken into effect when you reboot. To change the timezone immediately you will need to link or copy it to {{ic|/etc/localtime}}:<br />
<br />
# cp /usr/share/zoneinfo/America/Chicago /etc/localtime<br />
<br />
When you [[#Time Set|set the hardware clock]] the new time zone will be take used.<br />
<br />
== Time Set ==<br />
<br />
The hardware clock can be set either directly or from the system clock. To check the current hardware clock time and system clock time respectively (the hardware clock time is presented in localtime even if the hardware clock set to UTC):<br />
<br />
# hwclock --show<br />
$ date<br />
<br />
To set the hardware clock directly (the argument must be in local time, even if you keep your hardware clock in UTC.):<br />
<br />
# hwclock --set --date="YYYY-MM-DD hh:mm:ss"<br />
<br />
To set the system clock:<br />
<br />
# date MMDDhhmmYYYY<br />
<br />
The hardware clock can be set from the system clock and vice versa:<br />
<br />
# hwclock --systohc<br />
# hwclock --hctosys<br />
<br />
== Time Skew ==<br />
<br />
Every clock has a value that differs from ''real time'' (the best representation of which being [[Wikipedia:International Atomic Time|International Atomic Time]]), no clock is perfect. A quartz based electronic clock keeps imperfect time, but maintains a consistent inaccuracy. This base 'inaccuracy' is known as 'time skew' or 'time drift'. When the hardware clock is set with {{ic|hwclock}}, a new drift value is calculated in seconds per day. The drift value is calculated by using the difference between the new value set and the hardware clock value just before the set, taking into account the value of the previous drift value and the last time time the hardware clock was set. The new drift value and the time when the clock was set is written to the file {{ic|/var/lib/hwclock/adjtime}} overwriting the previous values.<br />
<br />
{{Note|If the hwclock has been set again less than 24 hours after a previous set, the drift is not recalculated as {{ic|hwclock}} considers the elaspsed time period too short to accurately calculate the drift.}}<br />
<br />
If the hardware clock keeps losing or gaining time in large increments, it is possible that an invalid drift has been recorded. This can happen if you have set the hardware clock time incorrectly or your [[#Time Standard|time standard]] is not synchronized with a Windows or Mac OS install. The drift value can be removed by removing the file {{ic|/var/lib/hwclock/adjtime}}, then set the correct hardware clock and system clock time, and check if your [[#Time Standard|time standard]] is correct.<br />
<br />
The system clock is calculated by the Linux kernel as the number of seconds since midnight January 1st 1970 UTC. The initial value of the system clock is calculated from the hardware clock, dependent on the value of the HARDWARECLOCK defined in {{ic|/etc/rc.conf}}. Once power up has completed the system clock runs independently of the hardware clock. The Linux kernel keeps track of the system clock by counting timer interrupts. The software clock is very accurate but like most clocks is not perfectly accurate and will drift as well. Though rarely, the system clock can lose accuracy if the kernel skips interrupts. System clocks can be kept on accurate time by using [[NTP]]. NTP can also will adjust the interrupt frequency and the number of ticks per second to decrease system clock drift.<br />
<br />
== UTC in Windows ==<br />
<br />
Add the DWORD value:<br />
<br />
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\TimeZoneInformation\RealTimeIsUniversal<br />
<br />
with hexadecimal value 1 to the registry (through regedit). Windows XP and Windows Vista SP1 have support for setting the time standard as {{ic|UTC}} and can be activated in the same way however there is a bug after resuming from the suspend/hibernation state that resets the clock to {{ic|localtime}}. For these operating systems it is recommended to use {{ic|localtime}}.<br />
<br />
The hardware clock and system clock time may need to be [[#Setting the time|updated]] after setting this value.<br />
<br />
== Other Details ==<br />
<br />
* 32-bit Linux systems will stop working in 2038. Since system time is recorded as a 32-bit integer (the number of seconds since 1970 01 01) it's limitation will extend only this long.<br />
* If you regularly shutdown/reboot your computer numerous times in a day the recorded drift value will never get calculated, it may be worth occasionally to stay in Linux so it gets calculated.<br />
* The AUR application {{ic|adjtimex}} can adjust kernel time variables like interupt frequency to help improve the system clock time drift.<br />
* During kernel startup, at the point when the rtc driver is loaded, the system clock may or may not be set from the hwclock. Whether this occurs or not depends on the hardware platform, the version of the kernel and kernel build options. If this does occur at this point in the boot sequence, the hwclock time is assumed to be UTC and the value of {{ic|/proc/sys/class/rtcN/hctosys} (N=0,1,2,..) will be set to 1. Later during execution of rc.sysinit, the system clock is set again from the hardware clock dependent on the value of HARDWARECLOCK. Hence, setting hwclock to localtime may cause some unexepcted behaviour duing the boot sequence.<br />
<br />
== It's About 'Time' == <br />
<!-- This was the introduction to the original 'Time' article by [[User:Android]]; kept for nostalgia's sake. --><br />
<br />
Our concept of time speaks much more to our limited perception than it does to the nature of what we observe. Time is clearly the most fertile ground for a fundamental shift in the human conception of the objective natural universe.<br />
<br />
Time has been measured since the beginning of time, at least as a human concept. The most obvious natural marker of the passage of time is the progression of day and night. The "day" was the first known measure of time and still forms a fundamental part of timekeeping. Other cyclic natural phenomena are also historically associated with time; the word "tide" comes from a common etymological root. Even with computer timekeeping, the day is a fundamental concept.<br />
<br />
As the measurement of time has improved, standard measures of time have had to be revised. The "leapyear" accounts for the fact that the Earth's orbit around the sun is not exactly 365 days. With the advent of atomic clocks in the 1960s, it became clear that the Earth's daily rotation was gradually slowing down (primarily due to tidal friction). The definition of the second in terms of cesium atom oscillations is the basis of the time standard known as [[Wikipedia:International Atomic Time|'''I'''nternational '''A'''tomic '''T'''ime]], or '''TAI'''.<br />
<br />
The slow and irregular increase in the amount of time comprising a day occasionally causes problems with the POSIX definition of a day as 86400 seconds. This lead to the introduction of the "leapsecond" in 1972. Occasionally a second must be inserted into the normally defined UTC sequence in order to keep it synchronized with TAI.<br />
<br />
== Resources ==<br />
<br />
* [http://www.linuxsa.org.au/tips/time.html Linux Tips - Linux, Clocks, and Time]<br />
* [http://www.twinsun.com/tz/tz-link.htm Sources for Time Zone and Daylight Saving Time Data] for {{Pkg|tzdata}}<br />
* [http://www.ucolick.org/~sla/leapsecs/timescales.html Time Scales]<br />
* [[Wikipedia:Time]]</div>PeterLhttps://wiki.archlinux.org/index.php?title=System_time&diff=173880System time2011-12-12T22:27:52Z<p>PeterL: /* Time Skew */</p>
<hr />
<div>[[Category:Mainboards and BIOS (English)]] <!-- with regard to the hardware clock --><br />
[[Category:Daemons and system services (English)]] <!-- as the basis/rationale for NTP --><br />
{{i18n|Time}}<br />
{{Article summary start}}<br />
{{Article summary text|This article provides an introduction to the concept of keeping time on computers in general, and describes how clocks are configured and managed in Arch Linux.}}<br />
{{Article summary heading|Related}}<br />
{{Article summary wiki|Network Time Protocol}}<br />
{{Article summary wiki|rc.conf}}<br />
{{Article summary end}}<br />
<br />
This article explains how the time is read and set. The hardware clock (a.k.a. the Real Time Clock (RTC) or CMOS clock) and the system clock need to be set up correctly to maintain proper time. For ''maintaining'' accurate system time see [[Network Time Protocol]].<br />
<br />
== About ==<br />
<br />
The hardware clock stores the values of: Year, Month, Day, Hour, Minute, and the Seconds. The hardware clock time value will be of either of two standards: either the '''localtime''' standard, or the '''C'''oordinated '''U'''niversal '''T'''ime ('''UTC''') standard (also known as GMT, though conceptually different). The localtime standard is dependent on the current ''time zone'', while UTC is the ''global'' time standard and is independent of time zone values. The hardware clock can only store time values and does not have the ability to store the time standard (localtime or UTC), nor whether '''D'''aylight '''S'''aving '''T'''ime ('''DST''') is used.<br />
<br />
The hardware clock time standard (localtime or UTC) can be defined to most operating system's system clocks. By default, Windows uses localtime, Mac OS uses UTC, and UNIX-like operating systems vary. The system clock (a.k.a. the software clock) runs independent of the hardware clock and keeps track of: Time, Time Zone, and DST if applicable. Standard behavior of most operating systems is to set the system clock from the hardware clock on boot, keep accurate time of the system clock with an [[NTP]] program, and set the hardware clock from the system clock on shutdown. In Arch Linux, the daemon {{ic|/etc/rc.d/hwclock}} uses {{ic|hwclock}} to set the system and hardware clocks on boot and shutdown if 'hwclock' is in the DAEMONS list in {{ic|/etc/rc.conf}}).<br />
<br />
When using Linux it is beneficial to have the hardware clock set to the UTC standard and made known to all operating systems. Defining the hardware clock in Linux as UTC means that Daylight Savings Time will automatically be accounted for. If using the localtime standard the system clock will not be changed for DST occurances assuming that another operating system will take care of the DST switch (and provided no NTP agent is operating). <br />
<br />
== Time Standard ==<br />
<br />
You can set the hardware clock time standard through the command line. You can check what you have set your Arch Linux install to use by:<br />
<br />
$ grep ^HARDWARECLOCK /etc/rc.conf<br />
<br />
The hardware clock can be queried and set with the {{ic|hwclock}} command. To immediately change the hardware clock time standard to localtime use:<br />
<br />
# hwclock --localtime<br />
<br />
And to set it to UTC use:<br />
<br />
# hwclock --utc<br />
<br />
The time standard that the hardware clock uses will also need to be entered in your Arch Linux system configuration ([[rc.conf]]) so that the system clock will be correctly set on boot:<br />
<br />
HARDWARECLOCK="localtime"<br />
<br />
or<br />
<br />
HARDWARECLOCK="UTC"<br />
<br />
== Time Zone ==<br />
<br />
Be sure that your time zone is set correctly in {{ic|/etc/rc.conf}}. This is necessary not only for the localtime to be set correctly but also for other programs you may use. You can do this by:<br />
<br />
$ grep ^TIMEZONE /etc/rc.conf<br />
<br />
You can find the time zones listed in {{ic|/usr/share/zoneinfo/}} and then you will need to find a major city that exists to your time zone. If you live in a specialized time zone area these will be listed in sub-directories. An example configuration:<br />
<br />
TIMEZONE="America/Chicago"<br />
<br />
The new time zone will be taken into effect when you reboot. To change the timezone immediately you will need to link or copy it to {{ic|/etc/localtime}}:<br />
<br />
# cp /usr/share/zoneinfo/America/Chicago /etc/localtime<br />
<br />
When you [[#Time Set|set the hardware clock]] the new time zone will be take used.<br />
<br />
== Time Set ==<br />
<br />
The hardware clock can be set either directly or from the system clock. To check the current hardware clock time and system clock time respectively (the hardware clock time is presented in localtime even if the hardware clock set to UTC):<br />
<br />
# hwclock --show<br />
$ date<br />
<br />
To set the hardware clock directly (the argument must be in local time, even if you keep your hardware clock in UTC.):<br />
<br />
# hwclock --set --date="YYYY-MM-DD hh:mm:ss"<br />
<br />
To set the system clock:<br />
<br />
# date MMDDhhmmYYYY<br />
<br />
The hardware clock can be set from the system clock and vice versa:<br />
<br />
# hwclock --systohc<br />
# hwclock --hctosys<br />
<br />
== Time Skew ==<br />
<br />
Every clock has a value that differs from ''real time'' (the best representation of which being [[Wikipedia:International Atomic Time|International Atomic Time]]), no clock is perfect. A quartz based electronic clock keeps imperfect time, but maintains a consistent inaccuracy. This base 'inaccuracy' is known as 'time skew' or 'time drift'. When the hardware clock is set with {{ic|hwclock}}, a new drift value is calculated in seconds per day. The drift value is calculated by using the difference between the new value set and the hardware clock value just before the set, taking into account the value of the previous drift value and the last time time the hardware clock was set. The new drift value and the time when the clock was set is written to the file {{Filename|/var/lib/hwclock/adjtime}} overwriting the previous values.<br />
<br />
Note: If the hwclock has been set again less than 24 hours after a previous set; the drift is not recalculated as {{ic|hwclock}} considers the elaspsed time period too short to accurately calculate the drift. <br />
<br />
If the hardware clock keeps losing or gaining time in large increments, it is possible that an invalid drift has been recorded. This can happen if you have set the hardware clock time incorrectly or your [[#Time Standard|time standard]] is not synchronized with a Windows or Mac OS install. The drift value can be removed by removing the file {{Filename|/var/lib/hwclock/adjtime}}, then set the correct hardware clock and system clock time, and check if your [[#Time Standard|time standard]] is correct.<br />
<br />
The system clock is calculated by the Linux kernel as the number of seconds since midnight January 1st 1970 UTC. The initial value of the system clock is calculated from the hardware clock, dependent on the value of the HARDWARECLOCK defined in {{Filename|/etc/rc.conf}}. Once power up has completed the system clock runs independently of the hardware clock. The Linux kernel keeps track of the system clock by counting timer interrupts. The software clock is very accurate but like most clocks is not perfectly accurate and will drift as well. Though rarely, the system clock can lose accuracy if the kernel skips interrupts. System clocks can be kept on accurate time by using [[NTP]]. NTP can also will adjust the interrupt frequency and the number of ticks per second to decrease system clock drift.<br />
<br />
== UTC in Windows ==<br />
<br />
Add the DWORD value:<br />
<br />
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\TimeZoneInformation\RealTimeIsUniversal<br />
<br />
with hexadecimal value 1 to the registry (through regedit). Windows XP and Windows Vista SP1 have support for setting the time standard as {{ic|UTC}} and can be activated in the same way however there is a bug after resuming from the suspend/hibernation state that resets the clock to {{ic|localtime}}. For these operating systems it is recommended to use {{ic|localtime}}.<br />
<br />
The hardware clock and system clock time may need to be [[#Setting the time|updated]] after setting this value.<br />
<br />
== Other Details ==<br />
<br />
* 32-bit Linux systems will stop working in 2038. Since system time is recorded as a 32-bit integer (the number of seconds since 1970 01 01) it's limitation will extend only this long.<br />
* If you regularly shutdown/reboot your computer numerous times in a day the recorded drift value will never get calculated, it may be worth occasionally to stay in Linux so it gets calculated.<br />
* The AUR application {{ic|adjtimex}} can adjust kernel time variables like interupt frequency to help improve the system clock time drift.<br />
<br />
== It's About 'Time' == <br />
<!-- This was the introduction to the original 'Time' article by [[User:Android]]; kept for nostalgia's sake. --><br />
<br />
Our concept of time speaks much more to our limited perception than it does to the nature of what we observe. Time is clearly the most fertile ground for a fundamental shift in the human conception of the objective natural universe.<br />
<br />
Time has been measured since the beginning of time, at least as a human concept. The most obvious natural marker of the passage of time is the progression of day and night. The "day" was the first known measure of time and still forms a fundamental part of timekeeping. Other cyclic natural phenomena are also historically associated with time; the word "tide" comes from a common etymological root. Even with computer timekeeping, the day is a fundamental concept.<br />
<br />
As the measurement of time has improved, standard measures of time have had to be revised. The "leapyear" accounts for the fact that the Earth's orbit around the sun is not exactly 365 days. With the advent of atomic clocks in the 1960s, it became clear that the Earth's daily rotation was gradually slowing down (primarily due to tidal friction). The definition of the second in terms of cesium atom oscillations is the basis of the time standard known as [[Wikipedia:International Atomic Time|'''I'''nternational '''A'''tomic '''T'''ime]], or '''TAI'''.<br />
<br />
The slow and irregular increase in the amount of time comprising a day occasionally causes problems with the POSIX definition of a day as 86400 seconds. This lead to the introduction of the "leapsecond" in 1972. Occasionally a second must be inserted into the normally defined UTC sequence in order to keep it synchronized with TAI.<br />
<br />
== Resources ==<br />
<br />
* [http://www.linuxsa.org.au/tips/time.html Linux Tips - Linux, Clocks, and Time]<br />
* [http://www.twinsun.com/tz/tz-link.htm Sources for Time Zone and Daylight Saving Time Data] for {{Pkg|tzdata}}<br />
* [http://www.ucolick.org/~sla/leapsecs/timescales.html Time Scales]<br />
* [[Wikipedia:Time]]</div>PeterLhttps://wiki.archlinux.org/index.php?title=Daemons&diff=173879Daemons2011-12-12T22:16:39Z<p>PeterL: /* List of Daemons */</p>
<hr />
<div>[[Category:Boot process (English)]]<br />
[[Category:Daemons and system services (English)]]<br />
{{i18n|Daemon}}<br />
[[de:Daemons]]<br />
[[ro:Daemon]]<br />
<br />
A [[Wikipedia:Daemon (computing)|daemon]] is a program that runs in the background, waiting for events to occur and offering services. A good example is a web server that waits for a request to deliver a page or a ssh server waiting for someone trying to log in. While these are full featured applications, there are daemons whose work is not that visible. Daemons are for tasks like writing messages into a log file (e.g. syslog, metalog) or keeping your system time accurate (e.g. [[Network Time Protocol daemon|ntpd]]).<br />
<br />
{{Note|The word daemon is sometimes used for a class of programs that are started at boot but have no process which remains in memory. They are called daemons simply because they utilize the same startup/shutdown framework (e.g. {{ic|/etc/rc.d/}} scripts) used to start traditional daemons. For example, the {{ic|/etc/rc.d}} scripts for ''alsa'' and ''cpufreq'' provide persistent configuration support for their perspective kernel modules but do not start additional background processes to service requests or respond to events.<br />
<br />
From the user's perspective the distinction is typically not significant unless the user tries to look for the "daemon" in a process list.<br />
}}<br />
<br />
==Starting on Boot==<br />
A default install of Arch Linux will leave you with very few services (or daemons) enabled during boot. You can add or remove services by editing the {{ic|DAEMONS}} array in your [[rc.conf]] file. It will initially look something like this:<br />
DAEMONS=(syslog-ng network netfs crond)<br />
<br />
They will start in the order you have them listed. You can disable one and keep it in the array by prefixing it with an exclamation mark ({{ic|!}}). You can also have them start in the background by adding the {{ic|@}} symbol in front of it.<br />
<br />
Daemon scripts are stored in {{ic|/etc/rc.d/}}. You can print the list of all the available daemons on your system, along with their current status, with:<br />
$ rc.d list<br />
<br />
==Performing daemon actions manually==<br />
Every daemon has a series of actions that can be called with specific commands: usually there are at least {{ic|start}}, {{ic|stop}}, and {{ic|restart}}. You can issue each with:<br />
# /etc/rc.d/''daemon-name'' {start|stop|restart|...}<br />
A completely equivalent way is:<br />
# rc.d {start|stop|restart|...} ''daemon-name-1'' ''daemon-name-2'' ''daemon-name-3'' ...<br />
which, as it is clear from the example, works also with a list of daemons, calling for each the given action.<br />
<br />
For a list of all the available commands for a specific daemon, check its documentation, or just open the script in a text viewer.<br />
<br />
==Essentials==<br />
You do not have to add any more services, if you do not feel the need. However, a typical desktop user will add at least [[CUPS]] and [[dbus]]. As you install new services, you will have to manually add them to the {{ic|DAEMONS}} array in {{ic|/etc/rc.conf}}. (The {{ic|DAEMONS}} array is at the end of the default {{ic|rc.conf}} file.)<br />
<br />
==Starting Daemons in Background==<br />
This is helpful for starting a service and letting the next service start before the previous one has finished. Which services to start background depends on your needs. Do not background anything you need immediately. Here is an example:<br />
DAEMONS=(syslog-ng gensplash dbus network netfs @avahi-daemon @samba @crond @openntpd @cupsd @mpd)<br />
<br />
Starting {{ic|openntpd}} in the background could lead to synchronization errors between the actual time and the time stored on your computer. If you recognize an increasing time difference between your desktop clock and the actual time, try to start the {{ic|openntpd}} daemon normally and not in the background.<br />
<br />
==Rc.conf GUI Frontends==<br />
[[Rc.conf GUI Frontends]] allow you to easily change settings in {{ic|/etc/rc.conf}} using graphical application.<br />
<br />
==List of Daemons==<br />
Here is a list of daemons. Note that any package can provide a daemon, so this list will never be complete. Please feel free to add any missing daemons here, in alphabetical order.<br />
{| border="1"<br />
!Daemon!!Description<br />
|-<br />
|[[Acpid|acpid]]||Delivers ACPI events.<br />
|-<br />
|[[Advanced Linux Sound Architecture|alsa]]||Advanced Linux Sound Architecture; provides device drivers for sound cards.<br />
|-<br />
|atd||Run jobs queued for later execution.<br />
|-<br />
|[[Avahi|avahi-daemon]]||Allows programs to automatically find local network services.<br />
|-<br />
|[[Avahi|avahi-dnsconfd]]||<br />
|-<br />
|crond||Daemon to schedule and time events. The daemon name ''crond'' is used by at least two packages, {{Pkg|cronie}} and {{Pkg|dcron}}. See [[Cron]] for more information.<br />
|-<br />
|[[CUPS|cupsd]]||Common UNIX Printing System daemon.<br />
|-<br />
|[[D-Bus|dbus]]||Message bus system for software communication.<br />
|-<br />
|[[FAM|fam]]||File Alteration Monitor. (deprecated)<br />
|-<br />
|[[Fbsplash|fbsplash]]||Graphical boot splash screen for the user.<br />
|-<br />
|[[GDM|gdm]]||Gnome Display Manager (Login Screen)<br />
|-<br />
|[[Console Mouse Support|gpm]]||Console mouse support.<br />
|-<br />
|[[Fbsplash|gensplash]]||(see fbsplash)<br />
|-<br />
|[[HAL|hal]]||Hardware Abstraction Layer. (Deprecated)<br />
|-<br />
|[[LAMP|httpd]]||Apache HTTP Server (Web Server)<br />
|-<br />
|[[hwclock]]||Not a deamon as such, but on shutdowm, updates hwclock to compensate for drift.<br />
|-<br />
|[[MDADM|mdadm]]||MD Administration (Linux Software RAID).<br />
|-<br />
|[[Music Player Daemon|mpd]]||Music Player Daemon.<br />
|-<br />
|[[MySQL|mysqld]]||MySQL database server.<br />
|-<br />
|netfs||Mounts network file systems.<br />
|-<br />
|[[Configuring_Network|network]]||To bring up the network connections.<br />
|-<br />
|[[NetworkManager|networkmanager]]||Replace network, and provide configuration and detection for automatic network connections.<br />
|-<br />
|nsyslogd||<br />
|-<br />
|[[Network Time Protocol daemon|ntpd]]||Network Time Protocol daemon (client and server).<br />
|-<br />
|[[OpenNTPD|openntpd]]||alternate Network Time Protocol daemon (client and server).<br />
|-<br />
|[[Pure-FTPD|pure-ftpd]]||FTP server.<br />
|-<br />
|[[Powernowd|powernowd]]||To adjust speed of CPU depending on system load. See also [[CPU_Frequency_Scaling]]<br />
|-<br />
|[[Rsyslog|rsyslogd]]||The latest version of a system logger.<br />
|-<br />
|[[SLiM|slim]]||Simple Login Manager<br />
|-<br />
|[[Samba|samba]]||File and print services for Microsoft Windows clients.<br />
|-<br />
|[[USB_Scanner_Support|saned]]||To share the scanner system over network.<br />
|-<br />
|[[Lm_sensors|sensors]]||Hardware (temperature, fans etc) monitoring.<br />
|-<br />
|[[SMART|smartd]]||Self-Monitoring, Analysis, and Reporting Technology (S.M.A.R.T) Hard Disk Monitoring<br />
|-<br />
|[[Secure Shell|sshd]]||OpenSSH (secure shell) daemon.<br />
|-<br />
|stbd ||This daemon was previously necessary for gnome-system-tools. However, as of gnome-tools 2.28, it is no longer needed.<br />
|-<br />
|syslogd||This was the older and basic system logger.<br />
|-<br />
|[[Syslog-ng|syslog-ng]]||System logger next generation.<br />
|-<br />
|[[Timidity|timidity++]]||Software synthesizer for MIDI.<br />
|-<br />
|[[VirtualBox|vboxdrv]]||Necessary to run VirtualBox.<br />
|-<br />
|[[Very Secure FTP Daemon|vsftpd]]||FTP server.<br />
|-<br />
|[[Wicd|wicd]]||Combine with dbus to replace network, a lightweight alternative to NetworkManager.<br />
|-<br />
|}<br />
<br />
==See also==<br />
Examples for [[writing rc.d scripts]]</div>PeterLhttps://wiki.archlinux.org/index.php?title=System_time&diff=173871System time2011-12-12T21:47:31Z<p>PeterL: /* Time Skew */</p>
<hr />
<div>[[Category:Mainboards and BIOS (English)]] <!-- with regard to the hardware clock --><br />
[[Category:Daemons and system services (English)]] <!-- as the basis/rationale for NTP --><br />
{{i18n|Time}}<br />
{{Article summary start}}<br />
{{Article summary text|This article provides an introduction to the concept of keeping time on computers in general, and describes how clocks are configured and managed in Arch Linux.}}<br />
{{Article summary heading|Related}}<br />
{{Article summary wiki|Network Time Protocol}}<br />
{{Article summary wiki|rc.conf}}<br />
{{Article summary end}}<br />
<br />
This article explains how the time is read and set. The hardware clock (a.k.a. the Real Time Clock (RTC) or CMOS clock) and the system clock need to be set up correctly to maintain proper time. For ''maintaining'' accurate system time see [[Network Time Protocol]].<br />
<br />
== About ==<br />
<br />
The hardware clock stores the values of: Year, Month, Day, Hour, Minute, and the Seconds. The hardware clock time value will be of either of two standards: either the '''localtime''' standard, or the '''C'''oordinated '''U'''niversal '''T'''ime ('''UTC''') standard (also known as GMT, though conceptually different). The localtime standard is dependent on the current ''time zone'', while UTC is the ''global'' time standard and is independent of time zone values. The hardware clock can only store time values and does not have the ability to store the time standard (localtime or UTC), nor whether '''D'''aylight '''S'''aving '''T'''ime ('''DST''') is used.<br />
<br />
The hardware clock time standard (localtime or UTC) can be defined to most operating system's system clocks. By default, Windows uses localtime, Mac OS uses UTC, and UNIX-like operating systems vary. The system clock (a.k.a. the software clock) runs independent of the hardware clock and keeps track of: Time, Time Zone, and DST if applicable. Standard behavior of most operating systems is to set the system clock from the hardware clock on boot, keep accurate time of the system clock with an [[NTP]] program, and set the hardware clock from the system clock on shutdown. In Arch Linux, the daemon {{ic|/etc/rc.d/hwclock}} uses {{ic|hwclock}} to set the system and hardware clocks on boot and shutdown if 'hwclock' is in the DAEMONS list in {{ic|/etc/rc.conf}}).<br />
<br />
When using Linux it is beneficial to have the hardware clock set to the UTC standard and made known to all operating systems. Defining the hardware clock in Linux as UTC means that Daylight Savings Time will automatically be accounted for. If using the localtime standard the system clock will not be changed for DST occurances assuming that another operating system will take care of the DST switch (and provided no NTP agent is operating). <br />
<br />
== Time Standard ==<br />
<br />
You can set the hardware clock time standard through the command line. You can check what you have set your Arch Linux install to use by:<br />
<br />
$ grep ^HARDWARECLOCK /etc/rc.conf<br />
<br />
The hardware clock can be queried and set with the {{ic|hwclock}} command. To immediately change the hardware clock time standard to localtime use:<br />
<br />
# hwclock --localtime<br />
<br />
And to set it to UTC use:<br />
<br />
# hwclock --utc<br />
<br />
The time standard that the hardware clock uses will also need to be entered in your Arch Linux system configuration ([[rc.conf]]) so that the system clock will be correctly set on boot:<br />
<br />
HARDWARECLOCK="localtime"<br />
<br />
or<br />
<br />
HARDWARECLOCK="UTC"<br />
<br />
== Time Zone ==<br />
<br />
Be sure that your time zone is set correctly in {{ic|/etc/rc.conf}}. This is necessary not only for the localtime to be set correctly but also for other programs you may use. You can do this by:<br />
<br />
$ grep ^TIMEZONE /etc/rc.conf<br />
<br />
You can find the time zones listed in {{ic|/usr/share/zoneinfo/}} and then you will need to find a major city that exists to your time zone. If you live in a specialized time zone area these will be listed in sub-directories. An example configuration:<br />
<br />
TIMEZONE="America/Chicago"<br />
<br />
The new time zone will be taken into effect when you reboot. To change the timezone immediately you will need to link or copy it to {{ic|/etc/localtime}}:<br />
<br />
# cp /usr/share/zoneinfo/America/Chicago /etc/localtime<br />
<br />
When you [[#Time Set|set the hardware clock]] the new time zone will be take used.<br />
<br />
== Time Set ==<br />
<br />
The hardware clock can be set either directly or from the system clock. To check the current hardware clock time and system clock time respectively (the hardware clock time is presented in localtime even if the hardware clock set to UTC):<br />
<br />
# hwclock --show<br />
$ date<br />
<br />
To set the hardware clock directly (the argument must be in local time, even if you keep your hardware clock in UTC.):<br />
<br />
# hwclock --set --date="YYYY-MM-DD hh:mm:ss"<br />
<br />
To set the system clock:<br />
<br />
# date MMDDhhmmYYYY<br />
<br />
The hardware clock can be set from the system clock and vice versa:<br />
<br />
# hwclock --systohc<br />
# hwclock --hctosys<br />
<br />
== Time Skew ==<br />
<br />
Every clock has a value that differs from ''real time'' (the best representation of which being [[Wikipedia:International Atomic Time|International Atomic Time]]), no clock is perfect. A quartz based electronic clock keeps imperfect time, but maintains a consistent inaccuracy. This base 'inaccuracy' is known as 'time skew' or 'time drift'. When the hardware clock is set with {{ic|hwclock}}, a new drift value is calculated in seconds per day. The drift value is calculated by using the difference between the new value set and the hardware clock value just before the set, taking into account the value of the previous drift value and the last time time the hardware clock was set. The new drift value and the time when the clock was set is written to the file {{Filename|/var/lib/hwclock/adjtime}} overwriting the previous values.<br />
<br />
Note: If the hwclock has been set again less than 24 hours after a previous set; the drift is not recalculated as {{ic|hwclock}} considers the elaspsed time period too short to accurately calculate the drift. <br />
<br />
If the hardware clock keeps losing or gaining time in large increments, it is possible that an invalid drift has been recorded. This can happen if you have set the hardware clock time incorrectly or your [[#Time Standard|time standard]] is not synchronized with a Windows or Mac OS install. The drift value can be removed by removing the file {{Filename|/var/lib/hwclock/adjtime}}, then set the correct hardware clock and system clock time, and check if your [[#Time Standard|time standard]] is correct.<br />
<br />
The system clock is calculated by the Linux kernel as the number of seconds since midnight January 1st 1970 UTC. The initial value of the system clock is calculated from the hardware clock, dependent on the value of the HARDWARECLOCK defined in {{Filename|/etc/rc.conf}}. If HARDWARECLOCK is not defined, then the values in {{Filename|/var/lib/hwclock/adjtime}} are used when converting from hardware clock time to the initial system clock time. Once power up has completed the system clock runs independently of the hardware clock. The Linux kernel keeps track of the system clock by counting timer interrupts. The software clock is very accurate but like most clocks is not perfectly accurate and will drift as well. Though rarely, the system clock can lose accuracy if the kernel skips interrupts. System clocks can be kept on accurate time by using [[NTP]]. NTP can also will adjust the interrupt frequency and the number of ticks per second to decrease system clock drift.<br />
<br />
== UTC in Windows ==<br />
<br />
Add the DWORD value:<br />
<br />
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\TimeZoneInformation\RealTimeIsUniversal<br />
<br />
with hexadecimal value 1 to the registry (through regedit). Windows XP and Windows Vista SP1 have support for setting the time standard as {{ic|UTC}} and can be activated in the same way however there is a bug after resuming from the suspend/hibernation state that resets the clock to {{ic|localtime}}. For these operating systems it is recommended to use {{ic|localtime}}.<br />
<br />
The hardware clock and system clock time may need to be [[#Setting the time|updated]] after setting this value.<br />
<br />
== Other Details ==<br />
<br />
* 32-bit Linux systems will stop working in 2038. Since system time is recorded as a 32-bit integer (the number of seconds since 1970 01 01) it's limitation will extend only this long.<br />
* If you regularly shutdown/reboot your computer numerous times in a day the recorded drift value will never get calculated, it may be worth occasionally to stay in Linux so it gets calculated.<br />
* The AUR application {{ic|adjtimex}} can adjust kernel time variables like interupt frequency to help improve the system clock time drift.<br />
<br />
== It's About 'Time' == <br />
<!-- This was the introduction to the original 'Time' article by [[User:Android]]; kept for nostalgia's sake. --><br />
<br />
Our concept of time speaks much more to our limited perception than it does to the nature of what we observe. Time is clearly the most fertile ground for a fundamental shift in the human conception of the objective natural universe.<br />
<br />
Time has been measured since the beginning of time, at least as a human concept. The most obvious natural marker of the passage of time is the progression of day and night. The "day" was the first known measure of time and still forms a fundamental part of timekeeping. Other cyclic natural phenomena are also historically associated with time; the word "tide" comes from a common etymological root. Even with computer timekeeping, the day is a fundamental concept.<br />
<br />
As the measurement of time has improved, standard measures of time have had to be revised. The "leapyear" accounts for the fact that the Earth's orbit around the sun is not exactly 365 days. With the advent of atomic clocks in the 1960s, it became clear that the Earth's daily rotation was gradually slowing down (primarily due to tidal friction). The definition of the second in terms of cesium atom oscillations is the basis of the time standard known as [[Wikipedia:International Atomic Time|'''I'''nternational '''A'''tomic '''T'''ime]], or '''TAI'''.<br />
<br />
The slow and irregular increase in the amount of time comprising a day occasionally causes problems with the POSIX definition of a day as 86400 seconds. This lead to the introduction of the "leapsecond" in 1972. Occasionally a second must be inserted into the normally defined UTC sequence in order to keep it synchronized with TAI.<br />
<br />
== Resources ==<br />
<br />
* [http://www.linuxsa.org.au/tips/time.html Linux Tips - Linux, Clocks, and Time]<br />
* [http://www.twinsun.com/tz/tz-link.htm Sources for Time Zone and Daylight Saving Time Data] for {{Pkg|tzdata}}<br />
* [http://www.ucolick.org/~sla/leapsecs/timescales.html Time Scales]<br />
* [[Wikipedia:Time]]</div>PeterLhttps://wiki.archlinux.org/index.php?title=System_time&diff=173864System time2011-12-12T21:25:38Z<p>PeterL: /* Time Skew */</p>
<hr />
<div>[[Category:Mainboards and BIOS (English)]] <!-- with regard to the hardware clock --><br />
[[Category:Daemons and system services (English)]] <!-- as the basis/rationale for NTP --><br />
{{i18n|Time}}<br />
{{Article summary start}}<br />
{{Article summary text|This article provides an introduction to the concept of keeping time on computers in general, and describes how clocks are configured and managed in Arch Linux.}}<br />
{{Article summary heading|Related}}<br />
{{Article summary wiki|Network Time Protocol}}<br />
{{Article summary wiki|rc.conf}}<br />
{{Article summary end}}<br />
<br />
This article explains how the time is read and set. The hardware clock (a.k.a. the Real Time Clock (RTC) or CMOS clock) and the system clock need to be set up correctly to maintain proper time. For ''maintaining'' accurate system time see [[Network Time Protocol]].<br />
<br />
== About ==<br />
<br />
The hardware clock stores the values of: Year, Month, Day, Hour, Minute, and the Seconds. The hardware clock time value will be of either of two standards: either the '''localtime''' standard, or the '''C'''oordinated '''U'''niversal '''T'''ime ('''UTC''') standard (also known as GMT, though conceptually different). The localtime standard is dependent on the current ''time zone'', while UTC is the ''global'' time standard and is independent of time zone values. The hardware clock can only store time values and does not have the ability to store the time standard (localtime or UTC), nor whether '''D'''aylight '''S'''aving '''T'''ime ('''DST''') is used.<br />
<br />
The hardware clock time standard (localtime or UTC) can be defined to most operating system's system clocks. By default, Windows uses localtime, Mac OS uses UTC, and UNIX-like operating systems vary. The system clock (a.k.a. the software clock) runs independent of the hardware clock and keeps track of: Time, Time Zone, and DST if applicable. Standard behavior of most operating systems is to set the system clock from the hardware clock on boot, keep accurate time of the system clock with an [[NTP]] program, and set the hardware clock from the system clock on shutdown. In Arch Linux, the daemon {{ic|/etc/rc.d/hwclock}} uses {{ic|hwclock}} to set the system and hardware clocks on boot and shutdown if 'hwclock' is in the DAEMONS list in {{ic|/etc/rc.conf}}).<br />
<br />
When using Linux it is beneficial to have the hardware clock set to the UTC standard and made known to all operating systems. Defining the hardware clock in Linux as UTC means that Daylight Savings Time will automatically be accounted for. If using the localtime standard the system clock will not be changed for DST occurances assuming that another operating system will take care of the DST switch (and provided no NTP agent is operating). <br />
<br />
== Time Standard ==<br />
<br />
You can set the hardware clock time standard through the command line. You can check what you have set your Arch Linux install to use by:<br />
<br />
$ grep ^HARDWARECLOCK /etc/rc.conf<br />
<br />
The hardware clock can be queried and set with the {{ic|hwclock}} command. To immediately change the hardware clock time standard to localtime use:<br />
<br />
# hwclock --localtime<br />
<br />
And to set it to UTC use:<br />
<br />
# hwclock --utc<br />
<br />
The time standard that the hardware clock uses will also need to be entered in your Arch Linux system configuration ([[rc.conf]]) so that the system clock will be correctly set on boot:<br />
<br />
HARDWARECLOCK="localtime"<br />
<br />
or<br />
<br />
HARDWARECLOCK="UTC"<br />
<br />
== Time Zone ==<br />
<br />
Be sure that your time zone is set correctly in {{ic|/etc/rc.conf}}. This is necessary not only for the localtime to be set correctly but also for other programs you may use. You can do this by:<br />
<br />
$ grep ^TIMEZONE /etc/rc.conf<br />
<br />
You can find the time zones listed in {{ic|/usr/share/zoneinfo/}} and then you will need to find a major city that exists to your time zone. If you live in a specialized time zone area these will be listed in sub-directories. An example configuration:<br />
<br />
TIMEZONE="America/Chicago"<br />
<br />
The new time zone will be taken into effect when you reboot. To change the timezone immediately you will need to link or copy it to {{ic|/etc/localtime}}:<br />
<br />
# cp /usr/share/zoneinfo/America/Chicago /etc/localtime<br />
<br />
When you [[#Time Set|set the hardware clock]] the new time zone will be take used.<br />
<br />
== Time Set ==<br />
<br />
The hardware clock can be set either directly or from the system clock. To check the current hardware clock time and system clock time respectively (the hardware clock time is presented in localtime even if the hardware clock set to UTC):<br />
<br />
# hwclock --show<br />
$ date<br />
<br />
To set the hardware clock directly (the argument must be in local time, even if you keep your hardware clock in UTC.):<br />
<br />
# hwclock --set --date="YYYY-MM-DD hh:mm:ss"<br />
<br />
To set the system clock:<br />
<br />
# date MMDDhhmmYYYY<br />
<br />
The hardware clock can be set from the system clock and vice versa:<br />
<br />
# hwclock --systohc<br />
# hwclock --hctosys<br />
<br />
== Time Skew ==<br />
<br />
Every clock has a value that differs from ''real time'' (the best representation of which being [[Wikipedia:International Atomic Time|International Atomic Time]]), no clock is perfect. A quartz based electronic clock keeps imperfect time, but maintains a consistent inaccuracy. This base 'inaccuracy' is known as 'time skew' or 'time drift'. When the hardware clock is set with {{ic|hwclock}}, a new drift value is calculated in seconds per day. The drift value is calculated by using the difference between the new value set and the hardware clock value just before the set, taking into account the value of the previous drift value and the last time time the hardware clock was set. The new drift value and the time when the clock was set is written to the file {{ic|/var/lib/hwclock/adjtime}} overwriting the previous values.<br />
<br />
Note: If the hwclock has been set again less than 24 hours after a previous set; the drift is not recalculated as {{ic|hwclock}} considers the elaspsed time period too short to accurately calculate the drift. <br />
<br />
If the hardware clock keeps losing or gaining time in large increments, it is possible that an invalid drift has been recorded. This can happen if you have set the hardware clock time incorrectly or your [[#Time Standard|time standard]] is not synchronized with a Windows or Mac OS install. The drift value can be removed by removing the file {{Filename|/var/lib/hwclock/adjtime}}, then set the correct hardware clock and system clock time, and check if your [[#Time Standard|time standard]] is correct.<br />
<br />
The system clock is calculated by the Linux kernel as the number of seconds since midnight January 1st 1970 UTC. The initial value of the system clock is calculated from the hardware clock (after applying drift adjustment and converting to UTC) at power up and then runs independently of the hardware clock. The Linux kernel keeps track of the system clock by counting timer interrupts. The software clock is very accurate but like most clocks is not perfectly accurate and will drift as well. Though rarely, the system clock can lose accuracy if the kernel skips interrupts. System clocks can be kept on accurate time by using [[NTP]]. NTP can also will adjust the interrupt frequency and the number of ticks per second to decrease system clock drift.<br />
<br />
== UTC in Windows ==<br />
<br />
Add the DWORD value:<br />
<br />
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\TimeZoneInformation\RealTimeIsUniversal<br />
<br />
with hexadecimal value 1 to the registry (through regedit). Windows XP and Windows Vista SP1 have support for setting the time standard as {{ic|UTC}} and can be activated in the same way however there is a bug after resuming from the suspend/hibernation state that resets the clock to {{ic|localtime}}. For these operating systems it is recommended to use {{ic|localtime}}.<br />
<br />
The hardware clock and system clock time may need to be [[#Setting the time|updated]] after setting this value.<br />
<br />
== Other Details ==<br />
<br />
* 32-bit Linux systems will stop working in 2038. Since system time is recorded as a 32-bit integer (the number of seconds since 1970 01 01) it's limitation will extend only this long.<br />
* If you regularly shutdown/reboot your computer numerous times in a day the recorded drift value will never get calculated, it may be worth occasionally to stay in Linux so it gets calculated.<br />
* The AUR application {{ic|adjtimex}} can adjust kernel time variables like interupt frequency to help improve the system clock time drift.<br />
<br />
== It's About 'Time' == <br />
<!-- This was the introduction to the original 'Time' article by [[User:Android]]; kept for nostalgia's sake. --><br />
<br />
Our concept of time speaks much more to our limited perception than it does to the nature of what we observe. Time is clearly the most fertile ground for a fundamental shift in the human conception of the objective natural universe.<br />
<br />
Time has been measured since the beginning of time, at least as a human concept. The most obvious natural marker of the passage of time is the progression of day and night. The "day" was the first known measure of time and still forms a fundamental part of timekeeping. Other cyclic natural phenomena are also historically associated with time; the word "tide" comes from a common etymological root. Even with computer timekeeping, the day is a fundamental concept.<br />
<br />
As the measurement of time has improved, standard measures of time have had to be revised. The "leapyear" accounts for the fact that the Earth's orbit around the sun is not exactly 365 days. With the advent of atomic clocks in the 1960s, it became clear that the Earth's daily rotation was gradually slowing down (primarily due to tidal friction). The definition of the second in terms of cesium atom oscillations is the basis of the time standard known as [[Wikipedia:International Atomic Time|'''I'''nternational '''A'''tomic '''T'''ime]], or '''TAI'''.<br />
<br />
The slow and irregular increase in the amount of time comprising a day occasionally causes problems with the POSIX definition of a day as 86400 seconds. This lead to the introduction of the "leapsecond" in 1972. Occasionally a second must be inserted into the normally defined UTC sequence in order to keep it synchronized with TAI.<br />
<br />
== Resources ==<br />
<br />
* [http://www.linuxsa.org.au/tips/time.html Linux Tips - Linux, Clocks, and Time]<br />
* [http://www.twinsun.com/tz/tz-link.htm Sources for Time Zone and Daylight Saving Time Data] for {{Pkg|tzdata}}<br />
* [http://www.ucolick.org/~sla/leapsecs/timescales.html Time Scales]<br />
* [[Wikipedia:Time]]</div>PeterLhttps://wiki.archlinux.org/index.php?title=System_time&diff=144446System time2011-06-08T20:09:28Z<p>PeterL: /* About */</p>
<hr />
<div>[[Category:Mainboards and BIOS (English)]] <!-- with regard to the hardware clock --><br />
[[Category:Daemons and system services (English)]] <!-- as the basis/rationale for NTP --><br />
[[Category:Utilities (English)]] <!-- covers the hwclock utility --><br />
{{i18n|Time}}<br />
{{Article summary start}}<br />
{{Article summary text|This article provides an introduction to the concept of keeping time on computers in general, and describes how clocks are configured and managed in Arch Linux.}}<br />
{{Article summary heading|Related}}<br />
{{Article summary wiki|Network Time Protocol}}<br />
{{Article summary wiki|rc.conf}}<br />
{{Article summary end}}<br />
<br />
This article explains how to read and set the hardware clock (a.k.a. the Real Time Clock (RTC) or CMOS clock) and the system clock. For maintaining accurate system time, please see [[Network Time Protocol]].<br />
<br />
== About ==<br />
<br />
The hardware clock keeps values of year, month, day, hour, minute, and seconds. The hardware clock time value may either be in the '''localtime''' standard or the '''C'''oordinated '''U'''niversal '''T'''ime ('''UTC''') standard. Localtime is dependent on your local ''time zone'' while UTC (aka '''G'''reenwich '''M'''ean '''T'''ime) is ''global'' time and independent of time zone values. The hardware clock can only store time values and does not store information on whether localtime or UTC time is used, nor whether '''D'''aylight '''S'''aving '''T'''ime ('''DST''') is used. Common operating systems like Windows and Mac OS will set the hardware clock dependent on your time zone (localtime), while UNIX-like operating systems can be told to use either value. When using UNIX-like operating systems only, it is recommended to set the hardware clock to UTC. When dual booting with other operating systems it may be necessary to set the hardware clock to Localtime to avoid clocks becoming incorrect when switching back and forth between the different Operating systems (It is best to check that those other O/S can be configured to use UTC).<br />
<br />
Linux also has a software clock (aka the system clock) that runs independent of the hardware clock. The system clock keeps track of the time, time zone, and whether or not your location uses DST. The Arch Linux script ({{Filename|/etc/rc.d/hwclock}}) sets the system clock from the hardware clock on boot, and sets the hardware clock from the system clock on shutdown. Users must include 'hwclock' in the DEAMONS list in {{Filename|/etc/rc.conf}} for this to happen. Users often use [[NTP]] to keep the system clock set to the proper time.<br />
<br />
== Time Standard ==<br />
<br />
You can set the hardware clock time standard through the command line. You can check what you have set your Arch Linux install to use by:<br />
<br />
$ grep ^HARDWARECLOCK /etc/rc.conf<br />
<br />
To immediately change the hardware clock time standard, you can set localtime by:<br />
<br />
# hwclock --localtime<br />
<br />
And to set it as UTC by:<br />
<br />
# hwclock --utc<br />
<br />
The time standard that the hardware clock uses will also need to be entered in your Arch Linux system configuration ([[rc.conf]]) so that the system clock will be correctly set at restart (if the hwclock script is used):<br />
<br />
HARDWARECLOCK="localtime"<br />
<br />
or<br />
<br />
HARDWARECLOCK="UTC"<br />
<br />
{{Note|GNU/Linux will change to-and-from DST when the {{Codeline|HARDWARECLOCK}} setting is set to {{Codeline|UTC}}, regardless of whether GNU/Linux was running at the time DST is entered or left. When the {{Codeline|HARDWARECLOCK}} setting is set to {{Codeline|localtime}}, GNU/Linux will not adjust the time, operating under the assumption that you dual-boot and that the other OS takes care of the DST switch. If this is not the case, the DST change needs to be made manually.}}<br />
<br />
Your hardware clock and system clock time may need to be updated after this, read [[#Time Set]].<br />
<br />
== Time Zone ==<br />
<br />
Be sure that your time zone is set correctly in {{Filename|/etc/rc.conf}}, this not only is necessary for the localtime to be set correctly but also for other programs you may use. You can do this by:<br />
<br />
$ grep ^TIMEZONE /etc/rc.conf<br />
<br />
You can find the time zones listed in {{Filename|/usr/share/zoneinfo/}} and then you will need to find a major city that exists to your time zone. If you live in a specialized time zone area these will be listed in sub-directories. An example configuration:<br />
<br />
TIMEZONE="America/Chicago"<br />
<br />
The new time zone will be taken into effect when you reboot. To change the timezone immediately you will need to link it or copy it to {{Filename|/etc/localtime}}:<br />
<br />
rm /etc/localtime<br />
cp /usr/share/zoneinfo/America/Chicago /etc/localtime<br />
<br />
When you set the hardware clock in the next step the new time zone will be used.<br />
<br />
== Time Set ==<br />
<br />
The hardware clock can either be set directly or from the system clock. To check the current hardware clock time and system clock time respectively:<br />
<br />
$ hwclock --show<br />
$ date<br />
<br />
To set the hardware clock directly (in military time):<br />
<br />
# hwclock --set --date "MM/DD/YYYY hh:mm:ss"<br />
<br />
To set the system clock:<br />
<br />
# date MMDDhhmmYYYY<br />
<br />
The hardware clock can be set from the system clock and vice versa:<br />
<br />
# hwclock --systohc<br />
# hwclock --hctosys<br />
<br />
== Time Skew ==<br />
<br />
No clock is perfect. Every clock has a value that differs from 'real time' (the best representation of which being [[Wikipedia:International Atomic Time|International Atomic Time]]). A quartz based electronic clock keeps imperfect time, but maintains a very consistent inaccuracy. This base 'inaccuracy' is known as 'time skew' or 'time drift'. Each time the hardware clock is set with {{Codeline|hwclock}} (e.g. during shutdown), {{Codeline|hwclock}} uses the new value, the old value and last time the hardware clock was set to calculate the drift in seconds per day. If the hwclock has not been set within the previous 24 hours; {{Codeline|hwclock}} overwrites the previous drift with the new drift in the file {{Filename|/var/lib/hwclock/adjtime}}. An Arch Linux cron job script adjusts the hardware clock according to the recorded drift every hour. If you see that the hardware clock keeps losing or gaining time by large amounts, it is likely an invalid drift is recorded in {{Filename|/var/lib/hwclock/adjtime}}. This can happen if you have set the hardware clock time incorrectly, or your [[#Time Standard|time standard]] is not synchronized with a Windows or Mac OS install. To fix this remove {{Filename|/var/lib/hwclock/adjtime}}, set the correct hardware clock and system clock time, and check if your [[#Time Standard|time standard]] is correct.<br />
<br />
Note: If you always power down your PC more often than once a day, the drift in the {{Filename|/var/lib/hwclock/adjtime}} will never be recalibrated (after the initial value was written) as each shutdown ({{Codeline|hwclock}} set) will occur more often than once every 24 hours. It may be worth occasionally leaving the PC on for > 24 hours and then to make sure the system clock is synchronized to real time just before shutdown.<br />
<br />
The system clock is calculated by the Linux kernel as the number of seconds since midnight January 1st 1970 UTC. The initial value of the system clock is calculated from the hardware clock (after applying drift adjustment and converting to UTC) at power up and then runs independently of the hardware clock. The Linux kernel keeps track of the system clock by counting timer interrupts. The software clock is very accurate but like most clocks isn't perfectly accurate and will drift as well. Though rare, the system clock can loose accuracy if the kernel skips interrupts. System clocks can be kept on accurate time by use of [[NTP]]. [[NTP]] will adjust the interrupt frequency and the number of ticks per second to decrease system clock drift. These values can also be adjusted by using the {{Codeline|adjtimex}} application (from the AUR).<br />
<br />
Note: If you dont use NTP and your hwclock is more accuracy that your system clock, then the copying of system clock to hwclock in the {{Filename|/etc/rc.d/hwclock}} will cause your hwclock to become less accurate; in this case you need to modify {{Filename|/etc/rc.d/hwclock}} not to do this (by commenting out the call to hwclock --systohc in the stop case).<br />
<br />
== Resources ==<br />
<br />
* [http://www.linuxsa.org.au/tips/time.html Linux Tips - Linux, Clocks, and Time]<br />
* [http://www.twinsun.com/tz/tz-link.htm Sources for Time Zone and Daylight Saving Time Data] for {{Package Official|tzdata}}<br />
* [http://www.ucolick.org/~sla/leapsecs/timescales.html Time Scales]<br />
* [[Wikipedia:Time]]</div>PeterLhttps://wiki.archlinux.org/index.php?title=System_time&diff=144445System time2011-06-08T20:06:41Z<p>PeterL: /* Time Skew */</p>
<hr />
<div>[[Category:Mainboards and BIOS (English)]] <!-- with regard to the hardware clock --><br />
[[Category:Daemons and system services (English)]] <!-- as the basis/rationale for NTP --><br />
[[Category:Utilities (English)]] <!-- covers the hwclock utility --><br />
{{i18n|Time}}<br />
{{Article summary start}}<br />
{{Article summary text|This article provides an introduction to the concept of keeping time on computers in general, and describes how clocks are configured and managed in Arch Linux.}}<br />
{{Article summary heading|Related}}<br />
{{Article summary wiki|Network Time Protocol}}<br />
{{Article summary wiki|rc.conf}}<br />
{{Article summary end}}<br />
<br />
This article explains how to read and set the hardware clock (a.k.a. the Real Time Clock (RTC) or CMOS clock) and the system clock. For maintaining accurate system time, please see [[Network Time Protocol]].<br />
<br />
== About ==<br />
<br />
The hardware clock keeps values of year, month, day, hour, minute, and seconds. The hardware clock time value may either be in the '''localtime''' standard or the '''C'''oordinated '''U'''niversal '''T'''ime ('''UTC''') standard. Localtime is dependent on your local ''time zone'' while UTC (aka '''G'''reenwich '''M'''ean '''T'''ime) is ''global'' time and independent of time zone values. The hardware clock can only store time values and does not store information on whether localtime or UTC time is used, nor whether '''D'''aylight '''S'''aving '''T'''ime ('''DST''') is used. Common operating systems like Windows and Mac OS will set the hardware clock dependent on your time zone (localtime), while UNIX-like operating systems can be told to use either value. When using UNIX-like operating systems only, it is recommended to set the hardware clock to UTC. When dual booting with other operating systems it may be necessary to set the hardware clock to Localtime to avoid clocks becoming incorrect when switching back and forth between the different Operating systems (It is best to check that those other O/S can be configured to use UTC).<br />
<br />
Linux also has a software clock (aka the system clock) that runs independent of the hardware clock. The system clock keeps track of the time, time zone, and whether or not your location uses DST. The Arch Linux script ({{Filename|/etc/rc.d/hwclock}}) sets the system clock from the hardware clock on boot, and sets the hardware clock from the system clock on shutdown. Users must include 'hwclock in the DEAMONS list in {{Filename|/etc/rc.conf}} for this to happen. Users often use [[NTP]] to keep the system clock set to the proper time and hence may not need to run the hwclock script.<br />
<br />
== Time Standard ==<br />
<br />
You can set the hardware clock time standard through the command line. You can check what you have set your Arch Linux install to use by:<br />
<br />
$ grep ^HARDWARECLOCK /etc/rc.conf<br />
<br />
To immediately change the hardware clock time standard, you can set localtime by:<br />
<br />
# hwclock --localtime<br />
<br />
And to set it as UTC by:<br />
<br />
# hwclock --utc<br />
<br />
The time standard that the hardware clock uses will also need to be entered in your Arch Linux system configuration ([[rc.conf]]) so that the system clock will be correctly set at restart (if the hwclock script is used):<br />
<br />
HARDWARECLOCK="localtime"<br />
<br />
or<br />
<br />
HARDWARECLOCK="UTC"<br />
<br />
{{Note|GNU/Linux will change to-and-from DST when the {{Codeline|HARDWARECLOCK}} setting is set to {{Codeline|UTC}}, regardless of whether GNU/Linux was running at the time DST is entered or left. When the {{Codeline|HARDWARECLOCK}} setting is set to {{Codeline|localtime}}, GNU/Linux will not adjust the time, operating under the assumption that you dual-boot and that the other OS takes care of the DST switch. If this is not the case, the DST change needs to be made manually.}}<br />
<br />
Your hardware clock and system clock time may need to be updated after this, read [[#Time Set]].<br />
<br />
== Time Zone ==<br />
<br />
Be sure that your time zone is set correctly in {{Filename|/etc/rc.conf}}, this not only is necessary for the localtime to be set correctly but also for other programs you may use. You can do this by:<br />
<br />
$ grep ^TIMEZONE /etc/rc.conf<br />
<br />
You can find the time zones listed in {{Filename|/usr/share/zoneinfo/}} and then you will need to find a major city that exists to your time zone. If you live in a specialized time zone area these will be listed in sub-directories. An example configuration:<br />
<br />
TIMEZONE="America/Chicago"<br />
<br />
The new time zone will be taken into effect when you reboot. To change the timezone immediately you will need to link it or copy it to {{Filename|/etc/localtime}}:<br />
<br />
rm /etc/localtime<br />
cp /usr/share/zoneinfo/America/Chicago /etc/localtime<br />
<br />
When you set the hardware clock in the next step the new time zone will be used.<br />
<br />
== Time Set ==<br />
<br />
The hardware clock can either be set directly or from the system clock. To check the current hardware clock time and system clock time respectively:<br />
<br />
$ hwclock --show<br />
$ date<br />
<br />
To set the hardware clock directly (in military time):<br />
<br />
# hwclock --set --date "MM/DD/YYYY hh:mm:ss"<br />
<br />
To set the system clock:<br />
<br />
# date MMDDhhmmYYYY<br />
<br />
The hardware clock can be set from the system clock and vice versa:<br />
<br />
# hwclock --systohc<br />
# hwclock --hctosys<br />
<br />
== Time Skew ==<br />
<br />
No clock is perfect. Every clock has a value that differs from 'real time' (the best representation of which being [[Wikipedia:International Atomic Time|International Atomic Time]]). A quartz based electronic clock keeps imperfect time, but maintains a very consistent inaccuracy. This base 'inaccuracy' is known as 'time skew' or 'time drift'. Each time the hardware clock is set with {{Codeline|hwclock}} (e.g. during shutdown), {{Codeline|hwclock}} uses the new value, the old value and last time the hardware clock was set to calculate the drift in seconds per day. If the hwclock has not been set within the previous 24 hours; {{Codeline|hwclock}} overwrites the previous drift with the new drift in the file {{Filename|/var/lib/hwclock/adjtime}}. An Arch Linux cron job script adjusts the hardware clock according to the recorded drift every hour. If you see that the hardware clock keeps losing or gaining time by large amounts, it is likely an invalid drift is recorded in {{Filename|/var/lib/hwclock/adjtime}}. This can happen if you have set the hardware clock time incorrectly, or your [[#Time Standard|time standard]] is not synchronized with a Windows or Mac OS install. To fix this remove {{Filename|/var/lib/hwclock/adjtime}}, set the correct hardware clock and system clock time, and check if your [[#Time Standard|time standard]] is correct.<br />
<br />
Note: If you always power down your PC more often than once a day, the drift in the {{Filename|/var/lib/hwclock/adjtime}} will never be recalibrated (after the initial value was written) as each shutdown ({{Codeline|hwclock}} set) will occur more often than once every 24 hours. It may be worth occasionally leaving the PC on for > 24 hours and then to make sure the system clock is synchronized to real time just before shutdown.<br />
<br />
The system clock is calculated by the Linux kernel as the number of seconds since midnight January 1st 1970 UTC. The initial value of the system clock is calculated from the hardware clock (after applying drift adjustment and converting to UTC) at power up and then runs independently of the hardware clock. The Linux kernel keeps track of the system clock by counting timer interrupts. The software clock is very accurate but like most clocks isn't perfectly accurate and will drift as well. Though rare, the system clock can loose accuracy if the kernel skips interrupts. System clocks can be kept on accurate time by use of [[NTP]]. [[NTP]] will adjust the interrupt frequency and the number of ticks per second to decrease system clock drift. These values can also be adjusted by using the {{Codeline|adjtimex}} application (from the AUR).<br />
<br />
Note: If you dont use NTP and your hwclock is more accuracy that your system clock, then the copying of system clock to hwclock in the {{Filename|/etc/rc.d/hwclock}} will cause your hwclock to become less accurate; in this case you need to modify {{Filename|/etc/rc.d/hwclock}} not to do this (by commenting out the call to hwclock --systohc in the stop case).<br />
<br />
== Resources ==<br />
<br />
* [http://www.linuxsa.org.au/tips/time.html Linux Tips - Linux, Clocks, and Time]<br />
* [http://www.twinsun.com/tz/tz-link.htm Sources for Time Zone and Daylight Saving Time Data] for {{Package Official|tzdata}}<br />
* [http://www.ucolick.org/~sla/leapsecs/timescales.html Time Scales]<br />
* [[Wikipedia:Time]]</div>PeterLhttps://wiki.archlinux.org/index.php?title=System_time&diff=144444System time2011-06-08T20:00:51Z<p>PeterL: /* Time Skew */</p>
<hr />
<div>[[Category:Mainboards and BIOS (English)]] <!-- with regard to the hardware clock --><br />
[[Category:Daemons and system services (English)]] <!-- as the basis/rationale for NTP --><br />
[[Category:Utilities (English)]] <!-- covers the hwclock utility --><br />
{{i18n|Time}}<br />
{{Article summary start}}<br />
{{Article summary text|This article provides an introduction to the concept of keeping time on computers in general, and describes how clocks are configured and managed in Arch Linux.}}<br />
{{Article summary heading|Related}}<br />
{{Article summary wiki|Network Time Protocol}}<br />
{{Article summary wiki|rc.conf}}<br />
{{Article summary end}}<br />
<br />
This article explains how to read and set the hardware clock (a.k.a. the Real Time Clock (RTC) or CMOS clock) and the system clock. For maintaining accurate system time, please see [[Network Time Protocol]].<br />
<br />
== About ==<br />
<br />
The hardware clock keeps values of year, month, day, hour, minute, and seconds. The hardware clock time value may either be in the '''localtime''' standard or the '''C'''oordinated '''U'''niversal '''T'''ime ('''UTC''') standard. Localtime is dependent on your local ''time zone'' while UTC (aka '''G'''reenwich '''M'''ean '''T'''ime) is ''global'' time and independent of time zone values. The hardware clock can only store time values and does not store information on whether localtime or UTC time is used, nor whether '''D'''aylight '''S'''aving '''T'''ime ('''DST''') is used. Common operating systems like Windows and Mac OS will set the hardware clock dependent on your time zone (localtime), while UNIX-like operating systems can be told to use either value. When using UNIX-like operating systems only, it is recommended to set the hardware clock to UTC. When dual booting with other operating systems it may be necessary to set the hardware clock to Localtime to avoid clocks becoming incorrect when switching back and forth between the different Operating systems (It is best to check that those other O/S can be configured to use UTC).<br />
<br />
Linux also has a software clock (aka the system clock) that runs independent of the hardware clock. The system clock keeps track of the time, time zone, and whether or not your location uses DST. The Arch Linux script ({{Filename|/etc/rc.d/hwclock}}) sets the system clock from the hardware clock on boot, and sets the hardware clock from the system clock on shutdown. Users must include 'hwclock in the DEAMONS list in {{Filename|/etc/rc.conf}} for this to happen. Users often use [[NTP]] to keep the system clock set to the proper time and hence may not need to run the hwclock script.<br />
<br />
== Time Standard ==<br />
<br />
You can set the hardware clock time standard through the command line. You can check what you have set your Arch Linux install to use by:<br />
<br />
$ grep ^HARDWARECLOCK /etc/rc.conf<br />
<br />
To immediately change the hardware clock time standard, you can set localtime by:<br />
<br />
# hwclock --localtime<br />
<br />
And to set it as UTC by:<br />
<br />
# hwclock --utc<br />
<br />
The time standard that the hardware clock uses will also need to be entered in your Arch Linux system configuration ([[rc.conf]]) so that the system clock will be correctly set at restart (if the hwclock script is used):<br />
<br />
HARDWARECLOCK="localtime"<br />
<br />
or<br />
<br />
HARDWARECLOCK="UTC"<br />
<br />
{{Note|GNU/Linux will change to-and-from DST when the {{Codeline|HARDWARECLOCK}} setting is set to {{Codeline|UTC}}, regardless of whether GNU/Linux was running at the time DST is entered or left. When the {{Codeline|HARDWARECLOCK}} setting is set to {{Codeline|localtime}}, GNU/Linux will not adjust the time, operating under the assumption that you dual-boot and that the other OS takes care of the DST switch. If this is not the case, the DST change needs to be made manually.}}<br />
<br />
Your hardware clock and system clock time may need to be updated after this, read [[#Time Set]].<br />
<br />
== Time Zone ==<br />
<br />
Be sure that your time zone is set correctly in {{Filename|/etc/rc.conf}}, this not only is necessary for the localtime to be set correctly but also for other programs you may use. You can do this by:<br />
<br />
$ grep ^TIMEZONE /etc/rc.conf<br />
<br />
You can find the time zones listed in {{Filename|/usr/share/zoneinfo/}} and then you will need to find a major city that exists to your time zone. If you live in a specialized time zone area these will be listed in sub-directories. An example configuration:<br />
<br />
TIMEZONE="America/Chicago"<br />
<br />
The new time zone will be taken into effect when you reboot. To change the timezone immediately you will need to link it or copy it to {{Filename|/etc/localtime}}:<br />
<br />
rm /etc/localtime<br />
cp /usr/share/zoneinfo/America/Chicago /etc/localtime<br />
<br />
When you set the hardware clock in the next step the new time zone will be used.<br />
<br />
== Time Set ==<br />
<br />
The hardware clock can either be set directly or from the system clock. To check the current hardware clock time and system clock time respectively:<br />
<br />
$ hwclock --show<br />
$ date<br />
<br />
To set the hardware clock directly (in military time):<br />
<br />
# hwclock --set --date "MM/DD/YYYY hh:mm:ss"<br />
<br />
To set the system clock:<br />
<br />
# date MMDDhhmmYYYY<br />
<br />
The hardware clock can be set from the system clock and vice versa:<br />
<br />
# hwclock --systohc<br />
# hwclock --hctosys<br />
<br />
== Time Skew ==<br />
<br />
No clock is perfect. Every clock has a value that differs from 'real time' (the best representation of which being [[Wikipedia:International Atomic Time|International Atomic Time]]). A quartz based electronic clock keeps imperfect time, but maintains a very consistent inaccuracy. This base 'inaccuracy' is known as 'time skew' or 'time drift'. Each time the hardware clock is set with {{Codeline|hwclock}} (e.g. during shutdown), {{Codeline|hwclock}} uses the new value, the old value and last time the hardware clock was set to calculate the drift in seconds per day. If the hwclock has not been set within the previous 24 hours; {{Codeline|hwclock}} overwrites the previous drift with the new drift in the file {{Filename|/var/lib/hwclock/adjtime}}. An Arch Linux cron job script adjusts the hardware clock according to the recorded drift every hour. If you see that the hardware clock keeps losing or gaining time by large amounts, it is likely an invalid drift is recorded in {{Filename|/var/lib/hwclock/adjtime}}. This can happen if you have set the hardware clock time incorrectly, or your [[#Time Standard|time standard]] is not synchronized with a Windows or Mac OS install. To fix this remove {{Filename|/var/lib/hwclock/adjtime}}, set the correct hardware clock and system clock time, and check if your [[#Time Standard|time standard]] is correct.<br />
<br />
Note: If you always power down your PC more often than once a day, the drift in the {{Filename|/var/lib/hwclock/adjtime}} will never be recalibrated (after the initial value was written) as each shutdown ({{Codeline|hwclock}} set) will occur more often than once every 24 hours. It may be worth occasionally leaving the PC on for > 24 hours and then to make sure the system clock is synchronized to real time just before shutdown.<br />
<br />
The system clock is calculated by the Linux kernel as the number of seconds since midnight January 1st 1970 UTC. The initial value of the system clock is calculated from the hardware clock (after applying drift adjustment and converting to UTC) at power up and then runs independently of the hardware clock. The Linux kernel keeps track of the system clock by counting timer interrupts. The software clock is very accurate but like most clocks isn't perfectly accurate and will drift as well. Though rare, the system clock can loose accuracy if the kernel skips interrupts. System clocks can be kept on accurate time by use of [[NTP]]. [[NTP]] will adjust the interrupt frequency and the number of ticks per second to decrease system clock drift. These values can also be adjusted by using the {{Codeline|adjtimex}} application (from the AUR).<br />
<br />
Note: If you dont use NTP and your hwclock is more accuracy that your system clock, then the copying of system clock to hwclock in the {{Filename|/etc/rc.d/hwclock}} will cause your hwclock to become less accurate; in this case you need to modify {{Filename|/etc/rc.d/hwclock}} not to do this (by commenting out the call to hwclock in the STOP case.<br />
<br />
== Resources ==<br />
<br />
* [http://www.linuxsa.org.au/tips/time.html Linux Tips - Linux, Clocks, and Time]<br />
* [http://www.twinsun.com/tz/tz-link.htm Sources for Time Zone and Daylight Saving Time Data] for {{Package Official|tzdata}}<br />
* [http://www.ucolick.org/~sla/leapsecs/timescales.html Time Scales]<br />
* [[Wikipedia:Time]]</div>PeterLhttps://wiki.archlinux.org/index.php?title=System_time&diff=144441System time2011-06-08T19:31:25Z<p>PeterL: </p>
<hr />
<div>[[Category:Mainboards and BIOS (English)]] <!-- with regard to the hardware clock --><br />
[[Category:Daemons and system services (English)]] <!-- as the basis/rationale for NTP --><br />
[[Category:Utilities (English)]] <!-- covers the hwclock utility --><br />
{{i18n|Time}}<br />
{{Article summary start}}<br />
{{Article summary text|This article provides an introduction to the concept of keeping time on computers in general, and describes how clocks are configured and managed in Arch Linux.}}<br />
{{Article summary heading|Related}}<br />
{{Article summary wiki|Network Time Protocol}}<br />
{{Article summary wiki|rc.conf}}<br />
{{Article summary end}}<br />
<br />
This article explains how to read and set the hardware clock (a.k.a. the Real Time Clock (RTC) or CMOS clock) and the system clock. For maintaining accurate system time, please see [[Network Time Protocol]].<br />
<br />
== About ==<br />
<br />
The hardware clock keeps values of year, month, day, hour, minute, and seconds. The hardware clock time value may either be in the '''localtime''' standard or the '''C'''oordinated '''U'''niversal '''T'''ime ('''UTC''') standard. Localtime is dependent on your local ''time zone'' while UTC (aka '''G'''reenwich '''M'''ean '''T'''ime) is ''global'' time and independent of time zone values. The hardware clock can only store time values and does not store information on whether localtime or UTC time is used, nor whether '''D'''aylight '''S'''aving '''T'''ime ('''DST''') is used. Common operating systems like Windows and Mac OS will set the hardware clock dependent on your time zone (localtime), while UNIX-like operating systems can be told to use either value. When using UNIX-like operating systems only, it is recommended to set the hardware clock to UTC. When dual booting with other operating systems it may be necessary to set the hardware clock to Localtime to avoid clocks becoming incorrect when switching back and forth between the different Operating systems (It is best to check that those other O/S can be configured to use UTC).<br />
<br />
Linux also has a software clock (aka the system clock) that runs independent of the hardware clock. The system clock keeps track of the time, time zone, and whether or not your location uses DST. The Arch Linux script ({{Filename|/etc/rc.d/hwclock}}) sets the system clock from the hardware clock on boot, and sets the hardware clock from the system clock on shutdown. Users must include 'hwclock in the DEAMONS list in {{Filename|/etc/rc.conf}} for this to happen. Users often use [[NTP]] to keep the system clock set to the proper time and hence may not need to run the hwclock script.<br />
<br />
== Time Standard ==<br />
<br />
You can set the hardware wclock time standard through the command line. You can check what you have set your Arch Linux install to use by:<br />
<br />
$ grep ^HARDWARECLOCK /etc/rc.conf<br />
<br />
To immediately change the hardware clock time standard, you can set localtime by:<br />
<br />
# hwclock --localtime<br />
<br />
And to set it as UTC by:<br />
<br />
# hwclock --utc<br />
<br />
The time standard that the hardware clock uses will also need to be entered in your Arch Linux system configuration ([[rc.conf]]) so that the system clock will be correctly set at restart (if the hwclock script is used):<br />
<br />
HARDWARECLOCK="localtime"<br />
<br />
or<br />
<br />
HARDWARECLOCK="UTC"<br />
<br />
{{Note|GNU/Linux will change to-and-from DST when the {{Codeline|HARDWARECLOCK}} setting is set to {{Codeline|UTC}}, regardless of whether GNU/Linux was running at the time DST is entered or left. When the {{Codeline|HARDWARECLOCK}} setting is set to {{Codeline|localtime}}, GNU/Linux will not adjust the time, operating under the assumption that you dual-boot and that the other OS takes care of the DST switch. If this is not the case, the DST change needs to be made manually.}}<br />
<br />
Your hardware clock and system clock time may need to be updated after this, read [[#Time Set]].<br />
<br />
== Time Zone ==<br />
<br />
Be sure that your time zone is set correctly in {{Filename|/etc/rc.conf}}, this not only is necessary for the localtime to be set correctly but also for other programs you may use. You can do this by:<br />
<br />
$ grep ^TIMEZONE /etc/rc.conf<br />
<br />
You can find the time zones listed in {{Filename|/usr/share/zoneinfo/}} and then you will need to find a major city that exists to your time zone. If you live in a specialized time zone area these will be listed in sub-directories. An example configuration:<br />
<br />
TIMEZONE="America/Chicago"<br />
<br />
The new time zone will be taken into effect when you reboot. To change the timezone immediately you will need to link it or copy it to {{Filename|/etc/localtime}}:<br />
<br />
rm /etc/localtime<br />
cp /usr/share/zoneinfo/America/Chicago /etc/localtime<br />
<br />
When you set the hardware clock in the next step the new time zone will be used.<br />
<br />
== Time Set ==<br />
<br />
The hardware clock can either be set directly or from the system clock. To check the current hardware clock time and system clock time respectively:<br />
<br />
$ hwclock --show<br />
$ date<br />
<br />
To set the hardware clock directly (in military time):<br />
<br />
# hwclock --set --date "MM/DD/YYYY hh:mm:ss"<br />
<br />
To set the system clock:<br />
<br />
# date MMDDhhmmYYYY<br />
<br />
The hardware clock can be set from the system clock and vice versa:<br />
<br />
# hwclock --systohc<br />
# hwclock --hctosys<br />
<br />
== Time Skew ==<br />
<br />
No clock is perfect. Every clock has a value that differs from 'real time' (the best representation of which being [[Wikipedia:International Atomic Time|International Atomic Time]]). A quartz based electronic clock keeps imperfect time, but maintains a very consistent inaccuracy. This base 'inaccuracy' is known as 'time skew' or 'time drift'. Each time the hardware clock is set with {{Codeline|hwclock}} (e.g. during shutdown), {{Codeline|hwclock}} uses the new value, the old value and last time the hardware clock was set to calculate the drift in seconds per day. If the hwclock has not been set within the previous 24 hours; {{Codeline|hwclock}} overwrites the previous drift with the new drift in the file {{Filename|/var/lib/hwclock/adjtime}}. An Arch Linux cron job script adjusts the hardware clock according to the recorded drift every hour. If you see that the hardware clock keeps losing or gaining time by large amounts, it is likely an invalid drift is recorded in {{Filename|/var/lib/hwclock/adjtime}}. This can happen if you have set the hardware clock time incorrectly, or your [[#Time Standard|time standard]] is not synchronized with a Windows or Mac OS install. To fix this remove {{Filename|/var/lib/hwclock/adjtime}}, set the correct hardware clock and system clock time, and check if your [[#Time Standard|time standard]] is correct.<br />
<br />
Note: If you always power down your PC more often than once a day, the drift in the {{Filename|/var/lib/hwclock/adjtime}} will never be recalibrated (after the initial value was written) as each shutdown ({{Codeline|hwclock}} set) will occur more often than once every 24 hours. It may be worth occasionally leaving the PC on for > 24 hours and then to make sure the system clock is synchronized to real time just before shutdown.<br />
<br />
The system clock is calculated by the Linux kernel as the number of seconds since midnight January 1st 1970 UTC. The initial value of the system clock is calculated from the hardware clock (after applying drift adjustment and converting to UTC) at power up and then runs independently of the hardware clock. The Linux kernel keeps track of the system clock by counting timer interrupts. The software clock is very accurate but like most clocks isn't perfectly accurate and will drift as well. Though rare, the system clock can loose accuracy if the kernel skips interrupts. System clocks can be kept on accurate time by use of [[NTP]]. [[NTP]] will adjust the interrupt frequency and the number of ticks per second to decrease system clock drift. These values can also be adjusted by using the {{Codeline|adjtimex}} application (from the AUR).<br />
<br />
== Resources ==<br />
<br />
* [http://www.linuxsa.org.au/tips/time.html Linux Tips - Linux, Clocks, and Time]<br />
* [http://www.twinsun.com/tz/tz-link.htm Sources for Time Zone and Daylight Saving Time Data] for {{Package Official|tzdata}}<br />
* [http://www.ucolick.org/~sla/leapsecs/timescales.html Time Scales]<br />
* [[Wikipedia:Time]]</div>PeterLhttps://wiki.archlinux.org/index.php?title=System_time&diff=132527System time2011-03-02T00:26:39Z<p>PeterL: /* Time Skew */</p>
<hr />
<div>[[Category:Mainboards and BIOS (English)]] <!-- with regard to the hardware clock --><br />
[[Category:Daemons and system services (English)]] <!-- as the basis/rationale for NTP --><br />
[[Category:Utilities (English)]] <!-- covers the hwclock utility --><br />
{{i18n|Time}}<br />
{{Article summary start}}<br />
{{Article summary text|This article provides an introduction to the concept of keeping time on computers in general, and describes how clocks are configured and managed in Arch Linux.}}<br />
{{Article summary heading|Related}}<br />
{{Article summary wiki|Network Time Protocol}}<br />
{{Article summary wiki|rc.conf}}<br />
{{Article summary end}}<br />
<br />
This article explains how to read and set the hardware clock (a.k.a. the Real Time Clock (RTC) or CMOS clock) and the system clock. For maintaining accurate system time, please see [[Network Time Protocol]].<br />
<br />
== About ==<br />
<br />
The hardware clock keeps values of year, month, day, hour, minute, and seconds. The hardware clock time value may either be in the '''localtime''' standard or the '''C'''oordinated '''U'''niversal '''T'''ime ('''UTC''') standard. Localtime is dependent on your local ''time zone'' while UTC (aka '''G'''reenwich '''M'''ean '''T'''ime) is ''global'' time and independent of time zone values. The hardware clock can only store time values and does not store information on whether localtime or UTC time is used, nor whether daylight savings time is used. Common operating systems like Windows and Mac OS will set the hardware clock dependent on your time zone (localtime), while UNIX-like operating systems can be told to use either value. When using UNIX-like operating systems only, it is recommended to set the hardware clock to UTC. When dual booting with other operating systems it may be necessary to set the hardware clock to Localtime to avoid clocks becoming incorrect when switching back and forth between the different Operating systems.<br />
<br />
Linux also has a software clock (aka the system clock) that runs independent of the hardware clock. The system clock keeps track of the time, time zone, and whether or not your location uses '''D'''aylight '''S'''avings '''T'''ime ('''DST'''). The Arch Linux script ({{Filename|/etc/rc.sysinit}}) sets the system clock from the hardware clock on boot, and the script ({{Filename|/etc/rc.shutdown}}) sets the hardware clock from the system clock on shutdown. Users often use [[NTP]] to keep the system clock set to the proper time.<br />
<br />
== Time Standard ==<br />
<br />
You can set the time standard through the command line. You can check what you have set your Arch Linux install to use by:<br />
<br />
$ grep ^HARDWARECLOCK /etc/rc.conf<br />
<br />
To immediately change the hardware clock time standard, you can set localtime by (if you use Windows or Mac OS you will want to use this):<br />
<br />
# hwclock --localtime<br />
<br />
And to set it as UTC by:<br />
<br />
# hwclock --utc<br />
<br />
The time standard will also need to be entered in your Arch Linux system configuration ([[rc.conf]]) so that it will be set the next time you restart:<br />
<br />
HARDWARECLOCK="localtime"<br />
<br />
or<br />
<br />
HARDWARECLOCK="UTC"<br />
<br />
{{Note|GNU/Linux will change to-and-from DST when the {{Codeline|HARDWARECLOCK}} setting is set to {{Codeline|UTC}}, regardless of whether GNU/Linux was running at the time DST is entered or left. When the {{Codeline|HARDWARECLOCK}} setting is set to {{Codeline|localtime}}, GNU/Linux will not adjust the time, operating under the assumption that you dual-boot and that the other OS takes care of the DST switch. If this is not the case, the DST change needs to be made manually.}}<br />
<br />
Your hardware clock and system clock time may need to be updated after this, read [[#Time Set]].<br />
<br />
== Time Zone ==<br />
<br />
Be sure that your time zone is set correctly in {{Filename|/etc/rc.conf}}, this not only is necessary for the localtime to be set correctly but also for other programs you may use. You can do this by:<br />
<br />
$ grep ^TIMEZONE /etc/rc.conf<br />
<br />
You can find the time zones listed in {{Filename|/usr/share/zoneinfo/}} and then you will need to find a major city that exists to your time zone. If you live in a specialized time zone area these will be listed in sub-directories. An example configuration:<br />
<br />
TIMEZONE="America/Chicago"<br />
<br />
The new time zone will be taken into effect when you reboot. To change the timezone immediately you will need to link it or copy it to {{Filename|/etc/localtime}}:<br />
<br />
rm /etc/localtime<br />
cp /usr/share/zoneinfo/America/Chicago /etc/localtime<br />
<br />
When you set the hardware clock in the next step the new time zone will be used.<br />
<br />
== Time Set ==<br />
<br />
The hardware clock can either be set directly or from the system clock. To check the current hardware clock time and system clock time respectively:<br />
<br />
$ hwclock --show<br />
$ date<br />
<br />
To set the hardware clock directly (in military time):<br />
<br />
# hwclock --set --date "MM/DD/YYYY hh:mm:ss"<br />
<br />
To set the system clock:<br />
<br />
# date MMDDhhmmYYYY<br />
<br />
The hardware clock can be set from the system clock and vice versa:<br />
<br />
# hwclock --systohc<br />
# hwclock --hctosys<br />
<br />
== Time Skew ==<br />
<br />
No clock is perfect. Every clock has a value that differs from 'real time' (the best representation of which being [[Wikipedia:International Atomic Time|International Atomic Time]]). A quartz based electronic clock keeps imperfect time, but maintains a very consistent inaccuracy. This base 'inaccuracy' is known as 'time skew' or 'time drift'. Each time the hardware clock is set with {{Codeline|hwclock}} (e.g. during shutdown), {{Codeline|hwclock}} uses the new value, the old value and last time the hardware clock was set to calculate the drift in seconds per day. If the hwclock has not been set within the previous 24 hours; {{Codeline|hwclock}} overwrites the previous drift with the new drift in the file {{Filename|/var/lib/hwclock/adjtime}}. An Arch Linux cron job script adjusts the hardware clock according to the recorded drift every hour. If you are seeing that the hardware clock keeps losing or gaining time by large amounts, it is likely an invalid drift is recorded in {{Filename|/var/lib/hwclock/adjtime}}. This can happen if you have set the hardware clock time incorrectly, or your [[#Time Standard|time standard]] is not syncronized with a Windows or Mac OS install. To fix this remove {{Filename|/var/lib/hwclock/adjtime}}, set the correct hardware clock and system clock time, and check if your [[#Time Standard|time standard]] is correct.<br />
<br />
Note: If you always power down your PC more often than once a day, the drift in the {{Filename|/var/lib/hwclock/adjtime}} will never be recalibrated (after the initial value was written) as each shutdown ({{Codeline|hwclock}} set) will occur more often than once every 24 hours. It may be worth occassionally leaving the PC on for > 24 hours and then to make sure the system clock is synchronised to real time just before shutdown. <br />
<br />
The system clock is calculated by the Linux kernel as the number of seconds since midnight January 1st 1970 UTC. The initial value of the system clock is calculated from the hardware clock (after applying drift adjustment and converting to UTC) at power up and then runs independently to the hardware clock. The Linux kernel keeps track of the system clock by counting timer interrupts. The software clock is very accurate but like most clocks isn't perfectly accurate and will drift as well. Though rare, the system clock can loose accuracy if the kernel skips interrupts. System clocks can be kept on accurate time by use of [[NTP]]. [[NTP]] will adjust the interrupt frequency and the number of ticks per second to decrease system clock drift. These values can also be adjusted by using the {{Codeline|adjtimex}} application (from the AUR).<br />
<br />
== Resources ==<br />
<br />
* [http://www.linuxsa.org.au/tips/time.html Linux Tips - Linux, Clocks, and Time]<br />
* [http://www.twinsun.com/tz/tz-link.htm Sources for Time Zone and Daylight Saving Time Data] for {{Package Official|tzdata}}<br />
* [http://www.ucolick.org/~sla/leapsecs/timescales.html Time Scales]<br />
* [[Wikipedia:Time]]</div>PeterLhttps://wiki.archlinux.org/index.php?title=System_time&diff=132526System time2011-03-02T00:18:14Z<p>PeterL: /* About */</p>
<hr />
<div>[[Category:Mainboards and BIOS (English)]] <!-- with regard to the hardware clock --><br />
[[Category:Daemons and system services (English)]] <!-- as the basis/rationale for NTP --><br />
[[Category:Utilities (English)]] <!-- covers the hwclock utility --><br />
{{i18n|Time}}<br />
{{Article summary start}}<br />
{{Article summary text|This article provides an introduction to the concept of keeping time on computers in general, and describes how clocks are configured and managed in Arch Linux.}}<br />
{{Article summary heading|Related}}<br />
{{Article summary wiki|Network Time Protocol}}<br />
{{Article summary wiki|rc.conf}}<br />
{{Article summary end}}<br />
<br />
This article explains how to read and set the hardware clock (a.k.a. the Real Time Clock (RTC) or CMOS clock) and the system clock. For maintaining accurate system time, please see [[Network Time Protocol]].<br />
<br />
== About ==<br />
<br />
The hardware clock keeps values of year, month, day, hour, minute, and seconds. The hardware clock time value may either be in the '''localtime''' standard or the '''C'''oordinated '''U'''niversal '''T'''ime ('''UTC''') standard. Localtime is dependent on your local ''time zone'' while UTC (aka '''G'''reenwich '''M'''ean '''T'''ime) is ''global'' time and independent of time zone values. The hardware clock can only store time values and does not store information on whether localtime or UTC time is used, nor whether daylight savings time is used. Common operating systems like Windows and Mac OS will set the hardware clock dependent on your time zone (localtime), while UNIX-like operating systems can be told to use either value. When using UNIX-like operating systems only, it is recommended to set the hardware clock to UTC. When dual booting with other operating systems it may be necessary to set the hardware clock to Localtime to avoid clocks becoming incorrect when switching back and forth between the different Operating systems.<br />
<br />
Linux also has a software clock (aka the system clock) that runs independent of the hardware clock. The system clock keeps track of the time, time zone, and whether or not your location uses '''D'''aylight '''S'''avings '''T'''ime ('''DST'''). The Arch Linux script ({{Filename|/etc/rc.sysinit}}) sets the system clock from the hardware clock on boot, and the script ({{Filename|/etc/rc.shutdown}}) sets the hardware clock from the system clock on shutdown. Users often use [[NTP]] to keep the system clock set to the proper time.<br />
<br />
== Time Standard ==<br />
<br />
You can set the time standard through the command line. You can check what you have set your Arch Linux install to use by:<br />
<br />
$ grep ^HARDWARECLOCK /etc/rc.conf<br />
<br />
To immediately change the hardware clock time standard, you can set localtime by (if you use Windows or Mac OS you will want to use this):<br />
<br />
# hwclock --localtime<br />
<br />
And to set it as UTC by:<br />
<br />
# hwclock --utc<br />
<br />
The time standard will also need to be entered in your Arch Linux system configuration ([[rc.conf]]) so that it will be set the next time you restart:<br />
<br />
HARDWARECLOCK="localtime"<br />
<br />
or<br />
<br />
HARDWARECLOCK="UTC"<br />
<br />
{{Note|GNU/Linux will change to-and-from DST when the {{Codeline|HARDWARECLOCK}} setting is set to {{Codeline|UTC}}, regardless of whether GNU/Linux was running at the time DST is entered or left. When the {{Codeline|HARDWARECLOCK}} setting is set to {{Codeline|localtime}}, GNU/Linux will not adjust the time, operating under the assumption that you dual-boot and that the other OS takes care of the DST switch. If this is not the case, the DST change needs to be made manually.}}<br />
<br />
Your hardware clock and system clock time may need to be updated after this, read [[#Time Set]].<br />
<br />
== Time Zone ==<br />
<br />
Be sure that your time zone is set correctly in {{Filename|/etc/rc.conf}}, this not only is necessary for the localtime to be set correctly but also for other programs you may use. You can do this by:<br />
<br />
$ grep ^TIMEZONE /etc/rc.conf<br />
<br />
You can find the time zones listed in {{Filename|/usr/share/zoneinfo/}} and then you will need to find a major city that exists to your time zone. If you live in a specialized time zone area these will be listed in sub-directories. An example configuration:<br />
<br />
TIMEZONE="America/Chicago"<br />
<br />
The new time zone will be taken into effect when you reboot. To change the timezone immediately you will need to link it or copy it to {{Filename|/etc/localtime}}:<br />
<br />
rm /etc/localtime<br />
cp /usr/share/zoneinfo/America/Chicago /etc/localtime<br />
<br />
When you set the hardware clock in the next step the new time zone will be used.<br />
<br />
== Time Set ==<br />
<br />
The hardware clock can either be set directly or from the system clock. To check the current hardware clock time and system clock time respectively:<br />
<br />
$ hwclock --show<br />
$ date<br />
<br />
To set the hardware clock directly (in military time):<br />
<br />
# hwclock --set --date "MM/DD/YYYY hh:mm:ss"<br />
<br />
To set the system clock:<br />
<br />
# date MMDDhhmmYYYY<br />
<br />
The hardware clock can be set from the system clock and vice versa:<br />
<br />
# hwclock --systohc<br />
# hwclock --hctosys<br />
<br />
== Time Skew ==<br />
<br />
No clock is perfect. Every clock has a value that differs from 'real time' (the best representation of which being [[Wikipedia:International Atomic Time|International Atomic Time]]). A quartz based electronic clock keeps imperfect time, but maintains a very consistent inaccuracy. This base 'inaccuracy' is known as 'time skew' or 'time drift'. Each time the hardware clock is set with {{Codeline|hwclock}} (e.g. during shutdown), {{Codeline|hwclock}} uses the new value, the old value and last time the hardware clock was set to calculate the drift in seconds per day. If the hwclock has not been set within the previous 24 hours; {{Codeline|hwclock}} overwrites the previous drift with the new drift in the file {{Filename|/var/lib/hwclock/adjtime}}. An Arch Linux cron job script adjusts the hardware clock according to the recorded drift every hour. If you are seeing that the hardware clock keeps losing or gaining time by large amounts, it is likely an invalid drift is recorded in {{Filename|/var/lib/hwclock/adjtime}}. This can happen if you have set the hardware clock time incorrectly, or your [[#Time Standard|time standard]] is not syncronized with a Windows or Mac OS install. To fix this remove {{Filename|/var/lib/hwclock/adjtime}}, set the correct hardware clock and system clock time, and check if your [[#Time Standard|time standard]] is correct.<br />
<br />
Note: If you always power down your PC more often than once a day, the drift in the {{Filename|/var/lib/hwclock/adjtime}} will never be recalibrated after the initial value was written as each shutdown ({{Codeline|hwclock}} set) will occur more often than once every 24 hours. It may be worth occassionally leaving the PC on for > 24 hours and then to set the system clock to real time just before shutdown. <br />
<br />
The system clock is calculated by the Linux kernel as the number of seconds since midnight January 1st 1970 UTC. The initial value of the system clock is calculated from the hardware clock (after applying drift adjustment and converting to UTC) at power up and then runs independently to the hardware clock. The Linux kernel keeps track of the system clock by counting timer interupts. The software clock is very accurate but like most clocks isn't perfectly accurate and will drift as well. Though rare, the system clock can loose accuracy if the kernel skips interrupts. System clocks can be kept on accurate time by use of [[NTP]].<br />
<br />
== Resources ==<br />
<br />
* [http://www.linuxsa.org.au/tips/time.html Linux Tips - Linux, Clocks, and Time]<br />
* [http://www.twinsun.com/tz/tz-link.htm Sources for Time Zone and Daylight Saving Time Data] for {{Package Official|tzdata}}<br />
* [http://www.ucolick.org/~sla/leapsecs/timescales.html Time Scales]<br />
* [[Wikipedia:Time]]</div>PeterLhttps://wiki.archlinux.org/index.php?title=System_time&diff=132525System time2011-03-02T00:15:48Z<p>PeterL: /* About */</p>
<hr />
<div>[[Category:Mainboards and BIOS (English)]] <!-- with regard to the hardware clock --><br />
[[Category:Daemons and system services (English)]] <!-- as the basis/rationale for NTP --><br />
[[Category:Utilities (English)]] <!-- covers the hwclock utility --><br />
{{i18n|Time}}<br />
{{Article summary start}}<br />
{{Article summary text|This article provides an introduction to the concept of keeping time on computers in general, and describes how clocks are configured and managed in Arch Linux.}}<br />
{{Article summary heading|Related}}<br />
{{Article summary wiki|Network Time Protocol}}<br />
{{Article summary wiki|rc.conf}}<br />
{{Article summary end}}<br />
<br />
This article explains how to read and set the hardware clock (a.k.a. the Real Time Clock (RTC) or CMOS clock) and the system clock. For maintaining accurate system time, please see [[Network Time Protocol]].<br />
<br />
== About ==<br />
<br />
The hardware clock keeps values of year, month, day, hour, minute, and seconds. The hardware clock time value may either be in the '''localtime''' standard or the '''C'''oordinated '''U'''niversal '''T'''ime ('''UTC''') standard. Localtime is dependent on your local ''time zone'' while UTC (aka '''G'''reenwich '''M'''ean '''T'''ime) is ''global'' time and independent of time zone values. The hardware clock can only store time values and does not store information on whether localtime or UTC time is used, nor whether daylight savings time is used. Common operating systems like Windows and Mac OS will set the hardware clock dependent on your time zone (localtime), while UNIX-like operating systems can be told to use either value. When using UNIX-like operating systems only, it is recommended to set the hardware clock to UTC (then daylight saving change works automatically). When dual booting with other operating systems it may be necessary to set the hardware clock to Localtime to avoid clocks becoming incorrect when switching back and forth between the different Operating systems. When set to Localtime, daylight saving changes will not work automatically without booting into the other Operating System.<br />
<br />
Linux also has a software clock (aka the system clock) that runs independent of the hardware clock. The system clock keeps track of the time, time zone, and whether or not your location uses '''D'''aylight '''S'''avings '''T'''ime ('''DST'''). The Arch Linux script ({{Filename|/etc/rc.sysinit}}) sets the system clock from the hardware clock on boot, and the script ({{Filename|/etc/rc.shutdown}}) sets the hardware clock from the system clock on shutdown. Users often use [[NTP]] to keep the system clock set to the proper time.<br />
<br />
== Time Standard ==<br />
<br />
You can set the time standard through the command line. You can check what you have set your Arch Linux install to use by:<br />
<br />
$ grep ^HARDWARECLOCK /etc/rc.conf<br />
<br />
To immediately change the hardware clock time standard, you can set localtime by (if you use Windows or Mac OS you will want to use this):<br />
<br />
# hwclock --localtime<br />
<br />
And to set it as UTC by:<br />
<br />
# hwclock --utc<br />
<br />
The time standard will also need to be entered in your Arch Linux system configuration ([[rc.conf]]) so that it will be set the next time you restart:<br />
<br />
HARDWARECLOCK="localtime"<br />
<br />
or<br />
<br />
HARDWARECLOCK="UTC"<br />
<br />
{{Note|GNU/Linux will change to-and-from DST when the {{Codeline|HARDWARECLOCK}} setting is set to {{Codeline|UTC}}, regardless of whether GNU/Linux was running at the time DST is entered or left. When the {{Codeline|HARDWARECLOCK}} setting is set to {{Codeline|localtime}}, GNU/Linux will not adjust the time, operating under the assumption that you dual-boot and that the other OS takes care of the DST switch. If this is not the case, the DST change needs to be made manually.}}<br />
<br />
Your hardware clock and system clock time may need to be updated after this, read [[#Time Set]].<br />
<br />
== Time Zone ==<br />
<br />
Be sure that your time zone is set correctly in {{Filename|/etc/rc.conf}}, this not only is necessary for the localtime to be set correctly but also for other programs you may use. You can do this by:<br />
<br />
$ grep ^TIMEZONE /etc/rc.conf<br />
<br />
You can find the time zones listed in {{Filename|/usr/share/zoneinfo/}} and then you will need to find a major city that exists to your time zone. If you live in a specialized time zone area these will be listed in sub-directories. An example configuration:<br />
<br />
TIMEZONE="America/Chicago"<br />
<br />
The new time zone will be taken into effect when you reboot. To change the timezone immediately you will need to link it or copy it to {{Filename|/etc/localtime}}:<br />
<br />
rm /etc/localtime<br />
cp /usr/share/zoneinfo/America/Chicago /etc/localtime<br />
<br />
When you set the hardware clock in the next step the new time zone will be used.<br />
<br />
== Time Set ==<br />
<br />
The hardware clock can either be set directly or from the system clock. To check the current hardware clock time and system clock time respectively:<br />
<br />
$ hwclock --show<br />
$ date<br />
<br />
To set the hardware clock directly (in military time):<br />
<br />
# hwclock --set --date "MM/DD/YYYY hh:mm:ss"<br />
<br />
To set the system clock:<br />
<br />
# date MMDDhhmmYYYY<br />
<br />
The hardware clock can be set from the system clock and vice versa:<br />
<br />
# hwclock --systohc<br />
# hwclock --hctosys<br />
<br />
== Time Skew ==<br />
<br />
No clock is perfect. Every clock has a value that differs from 'real time' (the best representation of which being [[Wikipedia:International Atomic Time|International Atomic Time]]). A quartz based electronic clock keeps imperfect time, but maintains a very consistent inaccuracy. This base 'inaccuracy' is known as 'time skew' or 'time drift'. Each time the hardware clock is set with {{Codeline|hwclock}} (e.g. during shutdown), {{Codeline|hwclock}} uses the new value, the old value and last time the hardware clock was set to calculate the drift in seconds per day. If the hwclock has not been set within the previous 24 hours; {{Codeline|hwclock}} overwrites the previous drift with the new drift in the file {{Filename|/var/lib/hwclock/adjtime}}. An Arch Linux cron job script adjusts the hardware clock according to the recorded drift every hour. If you are seeing that the hardware clock keeps losing or gaining time by large amounts, it is likely an invalid drift is recorded in {{Filename|/var/lib/hwclock/adjtime}}. This can happen if you have set the hardware clock time incorrectly, or your [[#Time Standard|time standard]] is not syncronized with a Windows or Mac OS install. To fix this remove {{Filename|/var/lib/hwclock/adjtime}}, set the correct hardware clock and system clock time, and check if your [[#Time Standard|time standard]] is correct.<br />
<br />
Note: If you always power down your PC more often than once a day, the drift in the {{Filename|/var/lib/hwclock/adjtime}} will never be recalibrated after the initial value was written as each shutdown ({{Codeline|hwclock}} set) will occur more often than once every 24 hours. It may be worth occassionally leaving the PC on for > 24 hours and then to set the system clock to real time just before shutdown. <br />
<br />
The system clock is calculated by the Linux kernel as the number of seconds since midnight January 1st 1970 UTC. The initial value of the system clock is calculated from the hardware clock (after applying drift adjustment and converting to UTC) at power up and then runs independently to the hardware clock. The Linux kernel keeps track of the system clock by counting timer interupts. The software clock is very accurate but like most clocks isn't perfectly accurate and will drift as well. Though rare, the system clock can loose accuracy if the kernel skips interrupts. System clocks can be kept on accurate time by use of [[NTP]].<br />
<br />
== Resources ==<br />
<br />
* [http://www.linuxsa.org.au/tips/time.html Linux Tips - Linux, Clocks, and Time]<br />
* [http://www.twinsun.com/tz/tz-link.htm Sources for Time Zone and Daylight Saving Time Data] for {{Package Official|tzdata}}<br />
* [http://www.ucolick.org/~sla/leapsecs/timescales.html Time Scales]<br />
* [[Wikipedia:Time]]</div>PeterLhttps://wiki.archlinux.org/index.php?title=System_time&diff=132524System time2011-03-02T00:14:23Z<p>PeterL: /* About */</p>
<hr />
<div>[[Category:Mainboards and BIOS (English)]] <!-- with regard to the hardware clock --><br />
[[Category:Daemons and system services (English)]] <!-- as the basis/rationale for NTP --><br />
[[Category:Utilities (English)]] <!-- covers the hwclock utility --><br />
{{i18n|Time}}<br />
{{Article summary start}}<br />
{{Article summary text|This article provides an introduction to the concept of keeping time on computers in general, and describes how clocks are configured and managed in Arch Linux.}}<br />
{{Article summary heading|Related}}<br />
{{Article summary wiki|Network Time Protocol}}<br />
{{Article summary wiki|rc.conf}}<br />
{{Article summary end}}<br />
<br />
This article explains how to read and set the hardware clock (a.k.a. the Real Time Clock (RTC) or CMOS clock) and the system clock. For maintaining accurate system time, please see [[Network Time Protocol]].<br />
<br />
== About ==<br />
<br />
The hardware clock keeps values of year, month, day, hour, minute, and seconds. The hardware clock time value may either be in the '''localtime''' standard or the '''C'''oordinated '''U'''niversal '''T'''ime ('''UTC''') standard. Localtime is dependent on your local ''time zone'' while UTC (aka '''G'''reenwich '''M'''ean '''T'''ime) is ''global'' time and independent of time zone values. The hardware clock can only store time values and does not store information on whether localtime or UTC time is used, nor whether daylight savings time is used. Common operating systems like Windows and Mac OS will set the hardware clock dependent on your time zone (localtime), while UNIX-like operating systems can be told to use either value. When using UNIX-like operating systems only, it is recommended to set the hardware clock to UTC (then daylight saving change works automatically). When dual booting with other operating systems it may be necessary to set the hardware clock to Localtime to avoid clocks becoming incorrect when switch back and forth between the different Operating systems. When set to Localtime, daylight saving changes will not work automatically without booting into the other Operating System.<br />
<br />
Linux also has a software clock (aka the system clock) that runs independent of the hardware clock. The system clock keeps track of the time, time zone, and whether or not your location uses '''D'''aylight '''S'''avings '''T'''ime ('''DST'''). The Arch Linux script ({{Filename|/etc/rc.sysinit}}) sets the system clock from the hardware clock on boot, and the script ({{Filename|/etc/rc.shutdown}}) sets the hardware clock from the system clock on shutdown. Users often use [[NTP]] to keep the system clock set to the proper time.<br />
<br />
== Time Standard ==<br />
<br />
You can set the time standard through the command line. You can check what you have set your Arch Linux install to use by:<br />
<br />
$ grep ^HARDWARECLOCK /etc/rc.conf<br />
<br />
To immediately change the hardware clock time standard, you can set localtime by (if you use Windows or Mac OS you will want to use this):<br />
<br />
# hwclock --localtime<br />
<br />
And to set it as UTC by:<br />
<br />
# hwclock --utc<br />
<br />
The time standard will also need to be entered in your Arch Linux system configuration ([[rc.conf]]) so that it will be set the next time you restart:<br />
<br />
HARDWARECLOCK="localtime"<br />
<br />
or<br />
<br />
HARDWARECLOCK="UTC"<br />
<br />
{{Note|GNU/Linux will change to-and-from DST when the {{Codeline|HARDWARECLOCK}} setting is set to {{Codeline|UTC}}, regardless of whether GNU/Linux was running at the time DST is entered or left. When the {{Codeline|HARDWARECLOCK}} setting is set to {{Codeline|localtime}}, GNU/Linux will not adjust the time, operating under the assumption that you dual-boot and that the other OS takes care of the DST switch. If this is not the case, the DST change needs to be made manually.}}<br />
<br />
Your hardware clock and system clock time may need to be updated after this, read [[#Time Set]].<br />
<br />
== Time Zone ==<br />
<br />
Be sure that your time zone is set correctly in {{Filename|/etc/rc.conf}}, this not only is necessary for the localtime to be set correctly but also for other programs you may use. You can do this by:<br />
<br />
$ grep ^TIMEZONE /etc/rc.conf<br />
<br />
You can find the time zones listed in {{Filename|/usr/share/zoneinfo/}} and then you will need to find a major city that exists to your time zone. If you live in a specialized time zone area these will be listed in sub-directories. An example configuration:<br />
<br />
TIMEZONE="America/Chicago"<br />
<br />
The new time zone will be taken into effect when you reboot. To change the timezone immediately you will need to link it or copy it to {{Filename|/etc/localtime}}:<br />
<br />
rm /etc/localtime<br />
cp /usr/share/zoneinfo/America/Chicago /etc/localtime<br />
<br />
When you set the hardware clock in the next step the new time zone will be used.<br />
<br />
== Time Set ==<br />
<br />
The hardware clock can either be set directly or from the system clock. To check the current hardware clock time and system clock time respectively:<br />
<br />
$ hwclock --show<br />
$ date<br />
<br />
To set the hardware clock directly (in military time):<br />
<br />
# hwclock --set --date "MM/DD/YYYY hh:mm:ss"<br />
<br />
To set the system clock:<br />
<br />
# date MMDDhhmmYYYY<br />
<br />
The hardware clock can be set from the system clock and vice versa:<br />
<br />
# hwclock --systohc<br />
# hwclock --hctosys<br />
<br />
== Time Skew ==<br />
<br />
No clock is perfect. Every clock has a value that differs from 'real time' (the best representation of which being [[Wikipedia:International Atomic Time|International Atomic Time]]). A quartz based electronic clock keeps imperfect time, but maintains a very consistent inaccuracy. This base 'inaccuracy' is known as 'time skew' or 'time drift'. Each time the hardware clock is set with {{Codeline|hwclock}} (e.g. during shutdown), {{Codeline|hwclock}} uses the new value, the old value and last time the hardware clock was set to calculate the drift in seconds per day. If the hwclock has not been set within the previous 24 hours; {{Codeline|hwclock}} overwrites the previous drift with the new drift in the file {{Filename|/var/lib/hwclock/adjtime}}. An Arch Linux cron job script adjusts the hardware clock according to the recorded drift every hour. If you are seeing that the hardware clock keeps losing or gaining time by large amounts, it is likely an invalid drift is recorded in {{Filename|/var/lib/hwclock/adjtime}}. This can happen if you have set the hardware clock time incorrectly, or your [[#Time Standard|time standard]] is not syncronized with a Windows or Mac OS install. To fix this remove {{Filename|/var/lib/hwclock/adjtime}}, set the correct hardware clock and system clock time, and check if your [[#Time Standard|time standard]] is correct.<br />
<br />
Note: If you always power down your PC more often than once a day, the drift in the {{Filename|/var/lib/hwclock/adjtime}} will never be recalibrated after the initial value was written as each shutdown ({{Codeline|hwclock}} set) will occur more often than once every 24 hours. It may be worth occassionally leaving the PC on for > 24 hours and then to set the system clock to real time just before shutdown. <br />
<br />
The system clock is calculated by the Linux kernel as the number of seconds since midnight January 1st 1970 UTC. The initial value of the system clock is calculated from the hardware clock (after applying drift adjustment and converting to UTC) at power up and then runs independently to the hardware clock. The Linux kernel keeps track of the system clock by counting timer interupts. The software clock is very accurate but like most clocks isn't perfectly accurate and will drift as well. Though rare, the system clock can loose accuracy if the kernel skips interrupts. System clocks can be kept on accurate time by use of [[NTP]].<br />
<br />
== Resources ==<br />
<br />
* [http://www.linuxsa.org.au/tips/time.html Linux Tips - Linux, Clocks, and Time]<br />
* [http://www.twinsun.com/tz/tz-link.htm Sources for Time Zone and Daylight Saving Time Data] for {{Package Official|tzdata}}<br />
* [http://www.ucolick.org/~sla/leapsecs/timescales.html Time Scales]<br />
* [[Wikipedia:Time]]</div>PeterLhttps://wiki.archlinux.org/index.php?title=System_time&diff=132523System time2011-03-02T00:12:16Z<p>PeterL: /* About */</p>
<hr />
<div>[[Category:Mainboards and BIOS (English)]] <!-- with regard to the hardware clock --><br />
[[Category:Daemons and system services (English)]] <!-- as the basis/rationale for NTP --><br />
[[Category:Utilities (English)]] <!-- covers the hwclock utility --><br />
{{i18n|Time}}<br />
{{Article summary start}}<br />
{{Article summary text|This article provides an introduction to the concept of keeping time on computers in general, and describes how clocks are configured and managed in Arch Linux.}}<br />
{{Article summary heading|Related}}<br />
{{Article summary wiki|Network Time Protocol}}<br />
{{Article summary wiki|rc.conf}}<br />
{{Article summary end}}<br />
<br />
This article explains how to read and set the hardware clock (a.k.a. the Real Time Clock (RTC) or CMOS clock) and the system clock. For maintaining accurate system time, please see [[Network Time Protocol]].<br />
<br />
== About ==<br />
<br />
The hardware clock keeps values of year, month, day, hour, minute, and seconds. The hardware clock time value may either be in the '''localtime''' standard or the '''C'''oordinated '''U'''niversal '''T'''ime ('''UTC''') standard. Localtime is dependent on your local ''time zone'' while UTC (aka '''G'''reenwich '''M'''ean '''T'''ime) is ''global'' time and independent of time zone values. The hardware clock can only store time values and does not store information on whether localtime or UTC time is used, nor whether daylight savings time is used. Common operating systems like Windows and Mac OS will set the hardware clock dependent on your time zone (localtime), while UNIX-like operating systems can be told to use either value. When the only using Linux it is recommended to set the hardware clock to UTC (then daylight saving change works automatically). When dual booting with other operating systems it may be necessary to set the hardware clock to Localtime to avoid clocks becoming incorrect when switch back and forth between the different Operating systems. When set to Localtime, daylight saving changes will not work automatically without booting into the other Operating System.<br />
<br />
Linux also has a software clock (aka the system clock) that runs independent of the hardware clock. The system clock keeps track of the time, time zone, and whether or not your location uses '''D'''aylight '''S'''avings '''T'''ime ('''DST'''). The Arch Linux script ({{Filename|/etc/rc.sysinit}}) sets the system clock from the hardware clock on boot, and the script ({{Filename|/etc/rc.shutdown}}) sets the hardware clock from the system clock on shutdown. Users often use [[NTP]] to keep the system clock set to the proper time.<br />
<br />
== Time Standard ==<br />
<br />
You can set the time standard through the command line. You can check what you have set your Arch Linux install to use by:<br />
<br />
$ grep ^HARDWARECLOCK /etc/rc.conf<br />
<br />
To immediately change the hardware clock time standard, you can set localtime by (if you use Windows or Mac OS you will want to use this):<br />
<br />
# hwclock --localtime<br />
<br />
And to set it as UTC by:<br />
<br />
# hwclock --utc<br />
<br />
The time standard will also need to be entered in your Arch Linux system configuration ([[rc.conf]]) so that it will be set the next time you restart:<br />
<br />
HARDWARECLOCK="localtime"<br />
<br />
or<br />
<br />
HARDWARECLOCK="UTC"<br />
<br />
{{Note|GNU/Linux will change to-and-from DST when the {{Codeline|HARDWARECLOCK}} setting is set to {{Codeline|UTC}}, regardless of whether GNU/Linux was running at the time DST is entered or left. When the {{Codeline|HARDWARECLOCK}} setting is set to {{Codeline|localtime}}, GNU/Linux will not adjust the time, operating under the assumption that you dual-boot and that the other OS takes care of the DST switch. If this is not the case, the DST change needs to be made manually.}}<br />
<br />
Your hardware clock and system clock time may need to be updated after this, read [[#Time Set]].<br />
<br />
== Time Zone ==<br />
<br />
Be sure that your time zone is set correctly in {{Filename|/etc/rc.conf}}, this not only is necessary for the localtime to be set correctly but also for other programs you may use. You can do this by:<br />
<br />
$ grep ^TIMEZONE /etc/rc.conf<br />
<br />
You can find the time zones listed in {{Filename|/usr/share/zoneinfo/}} and then you will need to find a major city that exists to your time zone. If you live in a specialized time zone area these will be listed in sub-directories. An example configuration:<br />
<br />
TIMEZONE="America/Chicago"<br />
<br />
The new time zone will be taken into effect when you reboot. To change the timezone immediately you will need to link it or copy it to {{Filename|/etc/localtime}}:<br />
<br />
rm /etc/localtime<br />
cp /usr/share/zoneinfo/America/Chicago /etc/localtime<br />
<br />
When you set the hardware clock in the next step the new time zone will be used.<br />
<br />
== Time Set ==<br />
<br />
The hardware clock can either be set directly or from the system clock. To check the current hardware clock time and system clock time respectively:<br />
<br />
$ hwclock --show<br />
$ date<br />
<br />
To set the hardware clock directly (in military time):<br />
<br />
# hwclock --set --date "MM/DD/YYYY hh:mm:ss"<br />
<br />
To set the system clock:<br />
<br />
# date MMDDhhmmYYYY<br />
<br />
The hardware clock can be set from the system clock and vice versa:<br />
<br />
# hwclock --systohc<br />
# hwclock --hctosys<br />
<br />
== Time Skew ==<br />
<br />
No clock is perfect. Every clock has a value that differs from 'real time' (the best representation of which being [[Wikipedia:International Atomic Time|International Atomic Time]]). A quartz based electronic clock keeps imperfect time, but maintains a very consistent inaccuracy. This base 'inaccuracy' is known as 'time skew' or 'time drift'. Each time the hardware clock is set with {{Codeline|hwclock}} (e.g. during shutdown), {{Codeline|hwclock}} uses the new value, the old value and last time the hardware clock was set to calculate the drift in seconds per day. If the hwclock has not been set within the previous 24 hours; {{Codeline|hwclock}} overwrites the previous drift with the new drift in the file {{Filename|/var/lib/hwclock/adjtime}}. An Arch Linux cron job script adjusts the hardware clock according to the recorded drift every hour. If you are seeing that the hardware clock keeps losing or gaining time by large amounts, it is likely an invalid drift is recorded in {{Filename|/var/lib/hwclock/adjtime}}. This can happen if you have set the hardware clock time incorrectly, or your [[#Time Standard|time standard]] is not syncronized with a Windows or Mac OS install. To fix this remove {{Filename|/var/lib/hwclock/adjtime}}, set the correct hardware clock and system clock time, and check if your [[#Time Standard|time standard]] is correct.<br />
<br />
Note: If you always power down your PC more often than once a day, the drift in the {{Filename|/var/lib/hwclock/adjtime}} will never be recalibrated after the initial value was written as each shutdown ({{Codeline|hwclock}} set) will occur more often than once every 24 hours. It may be worth occassionally leaving the PC on for > 24 hours and then to set the system clock to real time just before shutdown. <br />
<br />
The system clock is calculated by the Linux kernel as the number of seconds since midnight January 1st 1970 UTC. The initial value of the system clock is calculated from the hardware clock (after applying drift adjustment and converting to UTC) at power up and then runs independently to the hardware clock. The Linux kernel keeps track of the system clock by counting timer interupts. The software clock is very accurate but like most clocks isn't perfectly accurate and will drift as well. Though rare, the system clock can loose accuracy if the kernel skips interrupts. System clocks can be kept on accurate time by use of [[NTP]].<br />
<br />
== Resources ==<br />
<br />
* [http://www.linuxsa.org.au/tips/time.html Linux Tips - Linux, Clocks, and Time]<br />
* [http://www.twinsun.com/tz/tz-link.htm Sources for Time Zone and Daylight Saving Time Data] for {{Package Official|tzdata}}<br />
* [http://www.ucolick.org/~sla/leapsecs/timescales.html Time Scales]<br />
* [[Wikipedia:Time]]</div>PeterLhttps://wiki.archlinux.org/index.php?title=System_time&diff=132522System time2011-03-02T00:02:52Z<p>PeterL: /* Time Skew */</p>
<hr />
<div>[[Category:Mainboards and BIOS (English)]] <!-- with regard to the hardware clock --><br />
[[Category:Daemons and system services (English)]] <!-- as the basis/rationale for NTP --><br />
[[Category:Utilities (English)]] <!-- covers the hwclock utility --><br />
{{i18n|Time}}<br />
{{Article summary start}}<br />
{{Article summary text|This article provides an introduction to the concept of keeping time on computers in general, and describes how clocks are configured and managed in Arch Linux.}}<br />
{{Article summary heading|Related}}<br />
{{Article summary wiki|Network Time Protocol}}<br />
{{Article summary wiki|rc.conf}}<br />
{{Article summary end}}<br />
<br />
This article explains how to read and set the hardware clock (a.k.a. the Real Time Clock (RTC) or CMOS clock) and the system clock. For maintaining accurate system time, please see [[Network Time Protocol]].<br />
<br />
== About ==<br />
<br />
The hardware clock keeps values of year, month, day, hour, minute, and seconds. The hardware clock time value may either be in the '''localtime''' standard or the '''C'''oordinated '''U'''niversal '''T'''ime ('''UTC''') standard. Localtime is dependent on your local ''time zone'' while UTC (aka '''G'''reenwich '''M'''ean '''T'''ime) is ''global'' time and independent of time zone values. The hardware clock can only store time values and does not store information on whether localtime or UTC time is used, nor whether daylight savings time is used. Common operating systems like Windows and Mac OS will set the hardware clock dependent on your time zone (localtime), while UNIX-like operating systems can be told to use either value.<br />
<br />
Operating systems also have a software clock (aka the system clock) that runs independent of the hardware clock. The system clock keeps track of the time, time zone, and whether or not your location uses '''D'''aylight '''S'''avings '''T'''ime ('''DST'''). The Arch Linux script ({{Filename|/etc/rc.sysinit}}) sets the system clock from the hardware clock on boot, and the script ({{Filename|/etc/rc.shutdown}}) sets the hardware clock from the system clock on shutdown. Users often use [[NTP]] to keep the system clock set to the proper time.<br />
<br />
== Time Standard ==<br />
<br />
You can set the time standard through the command line. You can check what you have set your Arch Linux install to use by:<br />
<br />
$ grep ^HARDWARECLOCK /etc/rc.conf<br />
<br />
To immediately change the hardware clock time standard, you can set localtime by (if you use Windows or Mac OS you will want to use this):<br />
<br />
# hwclock --localtime<br />
<br />
And to set it as UTC by:<br />
<br />
# hwclock --utc<br />
<br />
The time standard will also need to be entered in your Arch Linux system configuration ([[rc.conf]]) so that it will be set the next time you restart:<br />
<br />
HARDWARECLOCK="localtime"<br />
<br />
or<br />
<br />
HARDWARECLOCK="UTC"<br />
<br />
{{Note|GNU/Linux will change to-and-from DST when the {{Codeline|HARDWARECLOCK}} setting is set to {{Codeline|UTC}}, regardless of whether GNU/Linux was running at the time DST is entered or left. When the {{Codeline|HARDWARECLOCK}} setting is set to {{Codeline|localtime}}, GNU/Linux will not adjust the time, operating under the assumption that you dual-boot and that the other OS takes care of the DST switch. If this is not the case, the DST change needs to be made manually.}}<br />
<br />
Your hardware clock and system clock time may need to be updated after this, read [[#Time Set]].<br />
<br />
== Time Zone ==<br />
<br />
Be sure that your time zone is set correctly in {{Filename|/etc/rc.conf}}, this not only is necessary for the localtime to be set correctly but also for other programs you may use. You can do this by:<br />
<br />
$ grep ^TIMEZONE /etc/rc.conf<br />
<br />
You can find the time zones listed in {{Filename|/usr/share/zoneinfo/}} and then you will need to find a major city that exists to your time zone. If you live in a specialized time zone area these will be listed in sub-directories. An example configuration:<br />
<br />
TIMEZONE="America/Chicago"<br />
<br />
The new time zone will be taken into effect when you reboot. To change the timezone immediately you will need to link it or copy it to {{Filename|/etc/localtime}}:<br />
<br />
rm /etc/localtime<br />
cp /usr/share/zoneinfo/America/Chicago /etc/localtime<br />
<br />
When you set the hardware clock in the next step the new time zone will be used.<br />
<br />
== Time Set ==<br />
<br />
The hardware clock can either be set directly or from the system clock. To check the current hardware clock time and system clock time respectively:<br />
<br />
$ hwclock --show<br />
$ date<br />
<br />
To set the hardware clock directly (in military time):<br />
<br />
# hwclock --set --date "MM/DD/YYYY hh:mm:ss"<br />
<br />
To set the system clock:<br />
<br />
# date MMDDhhmmYYYY<br />
<br />
The hardware clock can be set from the system clock and vice versa:<br />
<br />
# hwclock --systohc<br />
# hwclock --hctosys<br />
<br />
== Time Skew ==<br />
<br />
No clock is perfect. Every clock has a value that differs from 'real time' (the best representation of which being [[Wikipedia:International Atomic Time|International Atomic Time]]). A quartz based electronic clock keeps imperfect time, but maintains a very consistent inaccuracy. This base 'inaccuracy' is known as 'time skew' or 'time drift'. Each time the hardware clock is set with {{Codeline|hwclock}} (e.g. during shutdown), {{Codeline|hwclock}} uses the new value, the old value and last time the hardware clock was set to calculate the drift in seconds per day. If the hwclock has not been set within the previous 24 hours; {{Codeline|hwclock}} overwrites the previous drift with the new drift in the file {{Filename|/var/lib/hwclock/adjtime}}. An Arch Linux cron job script adjusts the hardware clock according to the recorded drift every hour. If you are seeing that the hardware clock keeps losing or gaining time by large amounts, it is likely an invalid drift is recorded in {{Filename|/var/lib/hwclock/adjtime}}. This can happen if you have set the hardware clock time incorrectly, or your [[#Time Standard|time standard]] is not syncronized with a Windows or Mac OS install. To fix this remove {{Filename|/var/lib/hwclock/adjtime}}, set the correct hardware clock and system clock time, and check if your [[#Time Standard|time standard]] is correct.<br />
<br />
Note: If you always power down your PC more often than once a day, the drift in the {{Filename|/var/lib/hwclock/adjtime}} will never be recalibrated after the initial value was written as each shutdown ({{Codeline|hwclock}} set) will occur more often than once every 24 hours. It may be worth occassionally leaving the PC on for > 24 hours and then to set the system clock to real time just before shutdown. <br />
<br />
The system clock is calculated by the Linux kernel as the number of seconds since midnight January 1st 1970 UTC. The initial value of the system clock is calculated from the hardware clock (after applying drift adjustment and converting to UTC) at power up and then runs independently to the hardware clock. The Linux kernel keeps track of the system clock by counting timer interupts. The software clock is very accurate but like most clocks isn't perfectly accurate and will drift as well. Though rare, the system clock can loose accuracy if the kernel skips interrupts. System clocks can be kept on accurate time by use of [[NTP]].<br />
<br />
== Resources ==<br />
<br />
* [http://www.linuxsa.org.au/tips/time.html Linux Tips - Linux, Clocks, and Time]<br />
* [http://www.twinsun.com/tz/tz-link.htm Sources for Time Zone and Daylight Saving Time Data] for {{Package Official|tzdata}}<br />
* [http://www.ucolick.org/~sla/leapsecs/timescales.html Time Scales]<br />
* [[Wikipedia:Time]]</div>PeterLhttps://wiki.archlinux.org/index.php?title=Blacklisting&diff=128779Blacklisting2011-01-23T11:23:28Z<p>PeterL: </p>
<hr />
<div>Blacklisting when refering to Kernel modules is a mechanism to stop the kernel module loading. This is either when the associated hardware is not required to be used, or loading that module causes problems. <br />
<br />
For example there may be a two kernel modules, that if they get loaded together try to control the same piece of hardware resulting in a conflict.<br />
<br />
Blacklisting can be done at boot time, see [[rc.conf]]; but this only applies at boot. Devices that get installed after boot e.g. USB or PCMCIA cards may still cause that module to be loaded. Or in the case of ipv6, get loaded as a dependency on some other module and hence still loads at boot even if blacklisted in [[rc.conf]].<br />
<br />
Alternative mechanism for blacklisting modules is to alias them in {{Filename|/etc/modprobe.d/modprobe.conf}}. Like so:<br />
<br />
blacklist net-pf-10<br />
<br />
In this case "net-pf-10" was an alias for ipv6.<br />
<br />
{{Note|Beware that this method does not always work.|}}<br />
<br />
The "blacklist" option blacklists modules loaded by that name only. But if some other module depends on that module, that module will get loaded because blacklisting does not match dependent modules.<br />
<br />
Alternative, one can force nothing to be installed by using the install option in {{Filename|/etc/modprobe.d/modprobe.conf}} like so:<br />
<br />
install MODULE_1 /bin/false<br />
install MODULE_2 /bin/false<br />
<br />
Note: some modules are loaded as part of the initramfs. [[mkinitcpio]] -M will print out all autodetected modules. Since this happens before rc.conf, blacklisting those modules in rc.conf has no effect. To avoid initramfs from loading those modules you wish to blacklist, then blacklist them in {{Filename|/etc/modprobe.d/modprobes.conf}}. Running [[mkinitcpio]] -v will list all modules<br />
pulled in by the various hooks (i.e. filesystem hook, SCSI hook, etc). Remember to rebuild initramfs once you've blacklisted the modules.</div>PeterLhttps://wiki.archlinux.org/index.php?title=Blacklisting&diff=128778Blacklisting2011-01-23T11:21:54Z<p>PeterL: </p>
<hr />
<div>Blacklisting when refering to Kernel modules is a mechanism to stop the kernel module loading. This is either when the associated hardware is not required to be used, or loading that module causes problems. <br />
<br />
For example there may be a two kernel modules, that if they get loaded together try to control the same piece of hardware resulting in a conflict.<br />
<br />
Blacklisting can be done at boot time, see [[rc.conf]]; but this only applies at boot. Devices that get installed after boot e.g. USB or PCMCIA cards may still cause that module to be loaded via udev. Or in the case of ipv6, get loaded as a dependency on some other module and hence still loads at boot even if blacklisted in [[rc.conf]].<br />
<br />
Alternative mechanism for blacklisting modules is to alias them in {{Filename|/etc/modprobe.d/modprobe.conf}}. Like so:<br />
<br />
blacklist net-pf-10<br />
<br />
In this case "net-pf-10" was an alias for ipv6.<br />
<br />
{{Note|Beware that this method does not always work.|}}<br />
<br />
The "blacklist" option blacklists modules loaded by that name only. But if some other module depends on that module, that module will get loaded because blacklisting does not match dependent modules.<br />
<br />
Alternative, one can force nothing to be installed by using the install option in {{Filename|/etc/modprobe.d/modprobe.conf}} like so:<br />
<br />
install MODULE_1 /bin/false<br />
install MODULE_2 /bin/false<br />
<br />
Note: some modules are loaded as part of the initramfs. [[mkinitcpio]] -M will print out all autodetected modules. Since this happens before rc.conf, blacklisting those modules in rc.conf has no effect. To avoid initramfs from loading those modules you wish to blacklist, then blacklist them in {{Filename|/etc/modprobe.d/modprobes.conf}}. Running [[mkinitcpio]] -v will list all modules<br />
pulled in by the various hooks (i.e. filesystem hook, SCSI hook, etc). Remember to rebuild initramfs once you've blacklisted the modules.</div>PeterLhttps://wiki.archlinux.org/index.php?title=Udev&diff=128775Udev2011-01-23T11:06:50Z<p>PeterL: /* Blacklisting Modules */</p>
<hr />
<div>[[Category:Hardware detection and troubleshooting (English)]]<br />
[[Category:HOWTOs (English)]]<br />
[[Category:Auto-mounting (English)]]<br />
{{i18n|Udev}}<br />
<br />
== Introduction ==<br />
''"udev is the device manager for the Linux 2.6 kernel series. Primarily, it manages device nodes in {{Filename|/dev}}. It is the successor of devfs and hotplug, which means that it handles the {{Filename|/dev}} directory and all user space actions when adding/removing devices, including firmware load."'' Source: [http://en.wikipedia.org/wiki/Udev Wikipedia]<br />
<br />
udev replaces the functionality of both {{Codeline|hotplug}} and {{Codeline|hwdetect}}.<br />
<br />
udev loads kernel modules by utilizing coding parallelism to provide a potential performance advantage versus loading these modules serially. The modules are therefore loaded asynchronously. The inherent disadvantage of this method is that udev does not always load modules in the same order on each boot. If the machine has multiple block devices, this may manifest itself in the form of device nodes changing designations randomly. For example, if the machine has two hard drives, /dev/sda may randomly become /dev/sdb. See below for more info on this.<br />
<br />
==About modules auto-loading==<br />
udev will not do ''any'' module loading for you unless {{Codeline|MOD_AUTOLOAD}} is enabled in {{Filename|/etc/rc.conf}}. If you disable auto-loading you must manually load the modules you want/need by putting the list in the {{Codeline|MODULES}} array in {{Filename|[[rc.conf]]}}, you can generate this list with the {{Codeline|hwdetect --modules}} command.<br />
<br />
==About udev rules==<br />
udev rules go in {{Filename|/etc/udev/rules.d/}}, their file name has to end with {{Filename|.rules}}.<br />
<br />
If you want to learn how to write udev rules see [http://www.reactivated.net/writing_udev_rules.html Writing udev rules].<br />
<br />
To get a list of all the attributes of a device you can use to write rules:<br />
# udevadm info -a -p $(udevadm info -q path -n [device name])<br />
<br />
Replace [device name] with the device present in the system, such as '/dev/sda' or '/dev/ttyUSB0'.<br />
<br />
To restart the udev system once you create or modify udev rules, run the following command. Hotpluggable devices, such as USB devices, will probably have to be reconnected for the new rules to take effect.<br />
# udevadm control restart<br />
<br />
== Tips & Tricks ==<br />
=== UDisks ===<br />
Simply install UDisks:<br />
pacman -S udisks<br />
and all your media should be auto mounted in GNOME and KDE SC 4.6. There is no need for any additional rules this way.<br />
As an extra bonus you can remove HAL if you were only using that for auto mounting purposes.<br />
<br />
==== UDisks Wrapper ====<br />
A UDisks wrapper has the advantage of being very easy to install and needing no (or minimal) configuration. The wrapper will automatically mount things like CDs and flash drives.<br />
<br />
* [[udiskie]] - Written in Python. Allows auto mount and unmount by any user.<br />
* [http://aur.archlinux.org/packages.php?ID=38723 udisksevt] - Written in Haskell. Allows auto mount by any user. Designed to be integrated with [http://aur.archlinux.org/packages.php?ID=32005 traydevice].<br />
<br />
==== UDisks Shell Functions ====<br />
While UDisks includes a simple method of (un)mounting devices via command-line, it can be tiresome to type the commands out each time. These shell functions will generally shorten and ease command-line usage.<br />
<br />
* [https://bbs.archlinux.org/viewtopic.php?id=109307 udisks_functions] - Written for Bash.<br />
<br />
=== Auto mounting USB devices ===<br />
{{Note|In the following rules the mount options are defined as {{Codeline|<nowiki>ENV{mount_options}="relatime"</nowiki>}}, see {{Codeline|man mount}} (and possibly {{Codeline|man ntfs-3g}}) for all available options and [[Maximizing Performance#Mount options]] for performance-related options.}}<br />
{{Note|The {{Codeline|users}} mount option will '''not''' allow users to unmount the filesystem.}}<br />
{{Tip|The {{Codeline|noexec}} mount option prevents execution of binaries on the mounted filesystem.}}<br />
<br />
==== Mount under {{Filename|/media}}; use partition label if present ====<br />
The following udev rule set automatically mounts devices/partitions that are represented by /dev/sd* (USB drives, external hard drives and sometimes SD cards). If a partition label is available, it mounts the device to /media/<label> and otherwise to /media/usbhd-sd* (ex: /media/usbhd-sdb1):<br />
{{File|name=/etc/udev/rules.d/11-media-by-label-auto-mount.rules|content=<nowiki><br />
KERNEL!="sd[a-z][0-9]", GOTO="media_by_label_auto_mount_end"<br />
<br />
# Import FS infos<br />
IMPORT{program}="/sbin/blkid -o udev -p %N"<br />
<br />
# Get a label if present, otherwise specify one<br />
ENV{ID_FS_LABEL}!="", ENV{dir_name}="%E{ID_FS_LABEL}"<br />
ENV{ID_FS_LABEL}=="", ENV{dir_name}="usbhd-%k"<br />
<br />
# Global mount options<br />
ACTION=="add", ENV{mount_options}="relatime"<br />
# Filesystem-specific mount options<br />
ACTION=="add", ENV{ID_FS_TYPE}=="vfat|ntfs", ENV{mount_options}="$env{mount_options},utf8,gid=100,umask=002"<br />
<br />
# Mount the device<br />
ACTION=="add", RUN+="/bin/mkdir -p /media/%E{dir_name}", RUN+="/bin/mount -o $env{mount_options} /dev/%k /media/%E{dir_name}"<br />
<br />
# Clean up after removal<br />
ACTION=="remove", ENV{dir_name}!="", RUN+="/bin/umount -l /media/%E{dir_name}", RUN+="/bin/rmdir /media/%E{dir_name}"<br />
<br />
# Exit<br />
LABEL="media_by_label_auto_mount_end"<br />
</nowiki>}}<br />
<br />
==== Mount under {{Filename|/media}}; use partition label if present; support LUKS encryption ====<br />
Similar to the above rule set, but if the device is a LUKS-encrypted partition it will open an xterm window to ask for the passphrase (provided that xterm is installed). Also see [http://bbs.archlinux.org/viewtopic.php?pid=696239#p696239 this post] and the follow-ups.<br />
<br />
{{Note|You may need to modify the path to cryptsetup, depending on the version installed (e.g., < 1.1.1_rc2-1).}}<br />
<br />
{{File|name=/etc/udev/rules.d/11-media-by-label-auto-mount.rules|content=<nowiki><br />
KERNEL!="sd[a-z]*", GOTO="media_by_label_auto_mount_end"<br />
ACTION=="add", PROGRAM!="/sbin/blkid %N", GOTO="media_by_label_auto_mount_end"<br />
<br />
# Do not mount devices on boot because otherwise fsck may fail<br />
ACTION=="add", PROGRAM!="/bin/grep ' / / rw[, ]' /proc/self/mountinfo", GOTO="media_by_label_auto_mount_end"<br />
<br />
# Open LUKS partition if necessary<br />
PROGRAM=="/sbin/blkid -o value -s TYPE %N", RESULT=="crypto_LUKS", ENV{crypto}="mapper/", ENV{device}="/dev/mapper/%k"<br />
ENV{crypto}=="", ENV{device}="%N"<br />
ACTION=="add", ENV{crypto}!="", PROGRAM=="/usr/bin/xterm -display :0.0 -e 'echo Password for /dev/%k; /sbin/cryptsetup luksOpen %N %k'"<br />
ACTION=="add", ENV{crypto}!="", TEST!="/dev/mapper/%k", GOTO="media_by_label_auto_mount_end"<br />
<br />
# Global mount options<br />
ACTION=="add", ENV{mount_options}="noatime"<br />
# Filesystem-specific mount options<br />
ACTION=="add", PROGRAM=="/sbin/blkid -o value -s TYPE %E{device}", RESULT=="vfat|ntfs", ENV{mount_options}="%E{mount_options},utf8,gid=100,umask=002"<br />
<br />
# Get label if present, otherwise assign one<br />
PROGRAM=="/sbin/blkid -o value -s LABEL %E{device}", ENV{dir_name}="%c"<br />
# Use basename to correctly handle labels such as ../mnt/foo<br />
PROGRAM=="/usr/bin/basename '%E{dir_name}'", ENV{dir_name}="%c"<br />
ENV{dir_name}=="", ENV{dir_name}="usbhd-%k"<br />
<br />
# Mount the device<br />
ACTION=="add", ENV{dir_name}!="", RUN+="/bin/mkdir -p '/media/%E{dir_name}'", RUN+="/bin/mount -o %E{mount_options} /dev/%E{crypto}%k '/media/%E{dir_name}'"<br />
<br />
# Clean up after removal<br />
ACTION=="remove", ENV{dir_name}!="", RUN+="/bin/umount -l '/media/%E{dir_name}'"<br />
ACTION=="remove", ENV{crypto}!="", RUN+="/sbin/cryptsetup luksClose %k"<br />
ACTION=="remove", ENV{dir_name}!="", RUN+="/bin/rmdir '/media/%E{dir_name}'"<br />
<br />
# Exit<br />
LABEL="media_by_label_auto_mount_end"<br />
</nowiki>}}<br />
<br />
==== Mount under {{Filename|/media}}; use partition label if present; support user un-mounting ====<br />
This is a variation on the above rule set. It uses pmount (which will need to be installed) instead of mount, allowing a non-root user to unmount udev-mounted devices. The required username must be hard-coded in the RUN command, so this rule set may not be suitable for multi-user systems. LUKS support has also been removed from the example, but can be easily reinstated as above. You must edit the /bin/su invocation to run as the correct user for your system.<br />
{{File|name=/etc/udev/rules.d/11-media-by-label-with-pmount.rules|content=<nowiki><br />
KERNEL!="sd[a-z]*", GOTO="media_by_label_auto_mount_end"<br />
ACTION=="add", PROGRAM!="/sbin/blkid %N", GOTO="media_by_label_auto_mount_end"<br />
<br />
# Get label<br />
PROGRAM=="/sbin/blkid -o value -s LABEL %N", ENV{dir_name}="%c"<br />
# use basename to correctly handle labels such as ../mnt/foo<br />
PROGRAM=="/usr/bin/basename '%E{dir_name}'", ENV{dir_name}="%c"<br />
ENV{dir_name}=="", ENV{dir_name}="usbhd-%k"<br />
<br />
ACTION=="add", ENV{dir_name}!="", RUN+="/bin/su tomk -c '/usr/bin/pmount %N %E{dir_name}'"<br />
ACTION=="remove", ENV{dir_name}!="", RUN+="/bin/su tomk -c '/usr/bin/pumount /media/%E{dir_name}'"<br />
LABEL="media_by_label_auto_mount_end"<br />
</nowiki>}}<br />
<br />
==== Mount under {{Filename|/mnt}}; create symbolic link under {{Filename|/media}} ====<br />
The following rule set does not make use of partition labels; instead it mounts devices as usbhd-sdXY under the /mnt directory (ex: /mnt/usbhd-sdb1) and creates a symbolic link under /media.<br />
{{File|name=/etc/udev/rules.d/11-mnt-auto-mount.rules|content=<nowiki><br />
KERNEL!="sd[a-z][0-9]", GOTO="mnt_auto_mount_end"<br />
<br />
# Global mount options<br />
ACTION=="add", ENV{mount_options}="relatime"<br />
# Filesystem-specific mount options<br />
ACTION=="add", IMPORT{program}="/sbin/blkid -o udev -p %N"<br />
ACTION=="add", ENV{ID_FS_TYPE}=="vfat|ntfs", ENV{mount_options}="$env{mount_options},utf8,gid=100,umask=002"<br />
<br />
# Mount under /mnt and create the symbolic link in /media <br />
ACTION=="add", RUN+="/bin/mount -o $env{mount_options} /dev/%k /mnt/usbhd-%k", RUN+="/bin/ln -s /mnt/usbhd-%k /media/usbhd-%k"<br />
<br />
# Clean up after removal<br />
ACTION=="remove", RUN+="/bin/rm -f /media/usbhd-%k", RUN+="/bin/umount -l /mnt/usbhd-%k", RUN+="/bin/rmdir /mnt/usbhd-%k"<br />
<br />
# Exit<br />
LABEL="mnt_auto_mount_end"<br />
</nowiki>}}<br />
<br />
==== Mount under {{Filename|/media}} ''only'' if the partition has a label ====<br />
{{File|name=/etc/udev/rules.d/11-media-by-label-only-auto-mount.rules|content=<nowiki><br />
KERNEL!="sd[a-z][0-9]", GOTO="media_by_label_only_auto_mount_end"<br />
<br />
# Import FS infos<br />
IMPORT{program}="/sbin/blkid -o udev -p %N"<br />
ENV{ID_FS_LABEL}=="", GOTO="media_by_label_only_auto_mount_end"<br />
<br />
# Global mount options<br />
ACTION=="add", ENV{mount_options}="relatime"<br />
# Filesystem-specific mount options<br />
ACTION=="add", ENV{ID_FS_TYPE}=="vfat|ntfs", ENV{mount_options}="$env{mount_options},utf8,gid=100,umask=002"<br />
<br />
# Mount the device<br />
ACTION=="add", RUN+="/bin/mkdir -p /media/$env{ID_FS_LABEL}", RUN+="/bin/mount -o $env{mount_options} /dev/%k /media/$env{ID_FS_LABEL}"<br />
<br />
# Clean up after removal<br />
ACTION=="remove", ENV{ID_FS_LABEL}!="", RUN+="/bin/umount -l /media/$env{ID_FS_LABEL}", RUN+="/bin/rmdir /media/$env{ID_FS_LABEL}"<br />
<br />
# Exit<br />
LABEL="media_by_label_only_auto_mount_end"<br />
</nowiki>}}<br />
<br />
==== Mount under {{Filename|/media}}; use partition label if present; ntfs-3g ====<br />
Yet another example, this time making use of ntfs-3g read/write drivers for NTFS filesystems:<br />
<br />
{{File|name=/etc/udev/rules.d/10-my-media-automount.rules|content=<nowiki><br />
# vim:enc=utf-8:nu:ai:si:et:ts=4:sw=4:ft=udevrules:<br />
#<br />
# /etc/udev/rules.d/10-my-media-automount.rules<br />
<br />
# start at sdb to ignore the system hard drive<br />
KERNEL!="sd[b-z]*", GOTO="my_media_automount_end"<br />
ACTION=="add", PROGRAM!="/sbin/blkid %N", GOTO="my_media_automount_end"<br />
<br />
# import some useful filesystem info as variables<br />
IMPORT{program}="/sbin/blkid -o udev -p %N"<br />
<br />
# get the label if present, otherwise assign one based on device/partition<br />
ENV{ID_FS_LABEL}!="", ENV{dir_name}="%E{ID_FS_LABEL}"<br />
ENV{ID_FS_LABEL}=="", ENV{dir_name}="usbhd-%k"<br />
<br />
# create the dir in /media and symlink it to /mnt<br />
ACTION=="add", RUN+="/bin/mkdir -p '/media/%E{dir_name}'"<br />
<br />
# global mount options<br />
ACTION=="add", ENV{mount_options}="relatime"<br />
# filesystem-specific mount options (777/666 dir/file perms for ntfs/vfat) <br />
ACTION=="add", ENV{ID_FS_TYPE}=="vfat|ntfs", ENV{mount_options}="$env{mount_options},gid=100,dmask=000,fmask=111,utf8"<br />
<br />
# automount ntfs filesystems using ntfs-3g driver<br />
ACTION=="add", ENV{ID_FS_TYPE}=="ntfs", RUN+="/bin/mount -t ntfs-3g -o %E{mount_options} /dev/%k '/media/%E{dir_name}'"<br />
# automount all other filesystems<br />
ACTION=="add", ENV{ID_FS_TYPE}!="ntfs", RUN+="/bin/mount -t auto -o %E{mount_options} /dev/%k '/media/%E{dir_name}'"<br />
<br />
# clean up after device removal<br />
ACTION=="remove", ENV{dir_name}!="", RUN+="/bin/umount -l '/media/%E{dir_name}'", RUN+="/bin/rmdir '/media/%E{dir_name}'"<br />
<br />
# exit<br />
LABEL="my_media_automount_end"<br />
<br />
</nowiki>}}<br />
<br />
==== Mount SD cards ====<br />
The same rules as above can be used to auto-mount SD cards, you just need to replace {{Codeline|sd[a-z][0-9]}} by {{Codeline|mmcblk[0-9]p[0-9]}}:<br />
{{File|name=/etc/udev/rules.d/11-sd-cards-auto-mount.rules|content=<nowiki><br />
KERNEL!="mmcblk[0-9]p[0-9]", GOTO="sd_cards_auto_mount_end"<br />
<br />
# Global mount options<br />
ACTION=="add", ENV{mount_options}="relatime"<br />
# Filesystem specific options<br />
ACTION=="add", IMPORT{program}="/sbin/blkid -o udev -p %N"<br />
ACTION=="add", ENV{ID_FS_TYPE}=="vfat|ntfs", ENV{mount_options}="$env{mount_options},utf8,gid=100,umask=002"<br />
<br />
ACTION=="add", RUN+="/bin/mkdir -p /media/sd-%k", RUN+="/bin/ln -s /media/sd-%k /mnt/sd-%k", RUN+="/bin/mount -o $env{mount_options} /dev/%k /media/sd-%k"<br />
ACTION=="remove", RUN+="/bin/umount -l /media/sd-%k", RUN+="/bin/rmdir /media/sd-%k"<br />
LABEL="sd_cards_auto_mount_end"<br />
</nowiki>}}<br />
<br />
==== Mount CDs ====<br />
To auto mount a CD a simple [[#UDisks Wrapper|UDisks wrapper]] will get the job done properly.<br />
{{Note|Maybe this should be merged to the Udisks wrapper section.}}<br />
<br />
==== Accessing Firmware Programmers and USB Virtual Comm Devices ====<br />
The following ruleset will allow normal users (within the "users" group) the ability to access the [http://www.ladyada.net/make/usbtinyisp/ USBtinyISP] USB programmer for AVR microcontrollers and a generic (SiLabs [http://www.silabs.com/products/interface/usbtouart CP2102]) USB to UART adapter. Adjust the permissions accordingly. Verified as of 2010-02-11.<br />
<br />
{{File|name=/etc/udev/rules.d/50-embedded_devices.rules|content=<nowiki><br />
# USBtinyISP Programmer rules<br />
SUBSYSTEMS=="usb", ATTRS{idVendor}=="1781", ATTRS{idProduct}=="0c9f", GROUP="users", MODE="0666"<br />
SUBSYSTEMS=="usb", ATTRS{idVendor}=="16c0", ATTRS{idProduct}=="0479", GROUP="users", MODE="0666"<br />
<br />
# Mdfly.com Generic (SiLabs CP2102) 3.3v/5v USB VComm adapter<br />
SUBSYSTEMS=="usb", ATTRS{idVendor}=="10c4", ATTRS{idProduct}=="ea60", GROUP="users", MODE="0666"<br />
</nowiki>}}<br />
<br />
=== Speed Up udev ===<br />
<br />
Performance gains can be realized by bypassing the blacklisting logic present in the {{Filename|/lib/udev/load-modules.sh}} script. See [[Speed_Up_udev]] for additional details.<br />
<br />
=== Execute on usb insert ===<br />
<br />
See the [[Execute_on_usb_insert|execute on usb insert]] article.<br />
<br />
==Troubleshooting==<br />
=== Disabling modules auto-loading with the load_modules boot parameter ===<br />
If you pass {{Codeline|<nowiki>load_modules=off</nowiki>}} on your kernel boot line, then udev will skip all the auto-loading business. This is to provide you with a big ripcord to pull if something goes wrong. If udev loads a problematic module that hangs your system or something equally awful, then you can bypass auto-loading with this parameter, then go in and blacklist the offensive module(s).<br />
<br />
=== Blacklisting Modules ===<br />
In rare cases, Udev can make mistakes and load the wrong modules. To prevent it from doing this, you can blacklist modules. Once blacklisted, udev will never load that module. See [[blacklisting]]. Not at boot-time ''or'' later on when a hotplug event is received (eg, you plug in your USB flash drive).<br />
<br />
=== Known Problems with Hardware ===<br />
====BusLogic devices can be broken and will cause a freeze during startup====<br />
This is a kernel bug and no fix has been provided yet.<br />
====PCMCIA Card readers are not treated as removable devices====<br />
To get access to them with hal's pmount backend add them to {{Filename|/etc/pmount.allow}}<br />
<br />
=== Known Problems with Auto-Loading ===<br />
==== CPU frequency modules ====<br />
The current detection method for the various CPU frequency controllers is inadequate, so this has been omitted from the auto-loading process for the time being. To use CPU frequency scaling, load the proper module explicitly in your {{Codeline|MODULES}} array in {{Filename|[[rc.conf]]}}.<br />
<br />
==== Sound Problems or Some Modules Not Loaded Automatically ====<br />
Some users have traced this problem to old entries in {{Codeline|/etc/modprobe.conf}}. Try cleaning that file out and trying again.<br />
<br />
==== Mixed Up Devices, Sound/Network Cards Changing Order Each Boot ====<br />
Because udev loads all modules asynchronously, they are initialized in a different order. This can result in devices randomly switching names. For example, with two network cards, you may notice a switching of designations between {{Codeline|eth0}} and {{Codeline|eth1}}.<br />
<br />
Arch Linux provides the advantage of specifying the module load order by listing the modules in the {{Codeline|MODULES}} array in {{Filename|[[rc.conf]]}}. Modules in this array are loaded before udev begins auto-loading, so you have full control over the load order.<br />
<br />
# Always load 8139too before e100<br />
MODULES=(8139too e100)<br />
<br />
<br />
Another method for network card ordering is to use the udev-sanctioned method of statically-naming each interface. Create the following file to bind the MAC address of each of your cards to a certain interface name:<br />
{{File|name=/etc/udev/rules.d/10-network.rules|content=<nowiki><br />
SUBSYSTEM=="net", ATTR{address}=="aa:bb:cc:dd:ee:ff", NAME="lan0"<br />
SUBSYSTEM=="net", ATTR{address}=="ff:ee:dd:cc:bb:aa", NAME="wlan0"<br />
</nowiki>}}<br />
<br />
A couple things to note:<br />
* To get the MAC address of each card, use this command: {{Codeline|<nowiki>udevadm info -a -p /sys/class/net/<yourdevice> | grep address | tr [A-Z] [a-z]</nowiki>}}<br />
* Make sure to use the lower-case hex values in your udev rules. It doesn't like upper-case.<br />
* Some people have problems naming their interfaces after the old style: eth0, eth1, etc. Try something like "lan" or "wlan" if you experience this problem.<br />
<br />
Don't forget to update your {{Filename|/etc/rc.conf}} and other configuration files using the old ethX notation!<br />
<br />
<br />
Another method for setting network interface names is described in the Configuring Network wiki entry.<br />
http://wiki.archlinux.org/index.php/Configuring_Network<br/><br />
http://wiki.archlinux.org/index.php/Configuring_Network#Interface_names_varying<br />
<br />
=== Known Problems for Custom Kernel Users ===<br />
==== Udev doesn't start at all ====<br />
Make sure you have a kernel version later than or equal to 2.6.15. Earlier kernels do not have the necessary uevent stuff that udev needs for auto-loading.<br />
<br />
==== CD/DVD symlinks and permissions are broken ====<br />
If you're using a 2.6.15 kernel, you'll need the uevent patch from ABS (which backports certain uevent functionality from 2.6.16). Just sync up your ABS tree with the {{Codeline|abs}} command, then you'll find the patch in {{Codeline|/var/abs/kernels/kernel26/}}.<br />
<br />
==Other Resources==<br />
* [http://www.kernel.org/pub/linux/utils/kernel/hotplug/udev.html Udev Homepage]<br />
* [http://www.linux.com/news/hardware/peripherals/180950-udev An Introduction to Udev]<br />
* [http://vger.kernel.org/vger-lists.html#linux-hotplug Udev mailing list information]</div>PeterLhttps://wiki.archlinux.org/index.php?title=Blacklisting&diff=128774Blacklisting2011-01-23T11:03:32Z<p>PeterL: </p>
<hr />
<div>Blacklisting when refering to Kernel modules is a mechanism to stop the kernel module loading. This is either when the associated hardware is not required to be used, or loading that module causes problems. <br />
<br />
For example there may be a two kernel modules, that if they get loaded together try to control the same piece of hardware resulting in a conflict.<br />
<br />
Blacklisting can be done at boot time, see [[rc.conf]]; but this only applies at boot. Devices that get installed after boot e.g. USB or PCMCIA cards may still cause that module to be loaded via udev. Or in the case of ipv6, get loaded as a dependency on some other module and hence still loads at boot even if blacklisted in [[rc.conf]].<br />
<br />
Alternative mechanism for blacklisting modules is to alias them in /etc/modprobe.d/modprobe.conf. Like so:<br />
<br />
blacklist net-pf-10<br />
<br />
In this case "net-pf-10" was an alias for ipv6.<br />
<br />
Note: some modules are loaded as part of the initramfs. [[mkinitcpio]] -M will print out all autodetected modules. Since this happens before rc.conf, blacklisting those modules in rc.conf has no effect. To avoid initramfs from loading thoses modules you wish to blacklist, then blacklist them in /etc/modprobe.d/modprobes.conf. Running [[mkinitcpio]] -v will list all modules<br />
pulled in by the various hooks (i.e. filesystem hook, SCSI hook, etc). Remember to rebuild initramfs once you've blacklisted the modules.</div>PeterLhttps://wiki.archlinux.org/index.php?title=Blacklisting&diff=128773Blacklisting2011-01-23T10:59:09Z<p>PeterL: </p>
<hr />
<div>Blacklisting when refering to Kernel modules is a mechanism to stop the kernel module loading. This is either when the associated hardware is not required to be used, or loading that module causes problems. <br />
<br />
For example there may be a two kernel modules, that if they get loaded together try to control the same piece of hardware resulting in a conflict.<br />
<br />
Blacklisting can be done at boot time, see [[rc.conf]]; but this only applies at boot. Devices that get installed after boot e.g. USB or PCMCIA cards may still cause that module to be loaded via udev. Or in the case of ipv6, get loaded as a dependency on some other module and hence still loads at boot even if blacklisted in [[rc.conf]].<br />
<br />
Alternative mechanism for blacklisting modules is to alias them in /etc/modprobe.d/modprobe.conf. Like so:<br />
<br />
blacklist net-pf-10<br />
<br />
In this case "net-pf-10" was an alias for ipv6.<br />
<br />
Note: some modules are loaded as part of the initramfs. mkinitcpio -M will print out all autodetected modules. Since this happens before rc.conf, blacklisting those modules in rc.conf has no effect. To avoid initramfs from loading thoses modules you wish to blacklist, then blacklist them in /etc/modprobe.d/modprobes.conf. Running mkinitcpio -v will list all modules<br />
pulled in by the various hooks (i.e. filesystem hook, SCSI hook, etc).</div>PeterLhttps://wiki.archlinux.org/index.php?title=Blacklisting&diff=128772Blacklisting2011-01-23T10:43:05Z<p>PeterL: </p>
<hr />
<div>Blacklisting when refering to Kernel modules is a mechanism to stop the kernel module loading. This is either when the associated hardware is not required to be used, or loading that module causes problems. <br />
<br />
For example there may be a two kernel modules, that if they get loaded together try to control the same piece of hardware resulting in a conflict.<br />
<br />
Blacklisting can be done at boot time, see [[rc.conf]]; but this only applies at boot. Devices that get installed after boot e.g. USB or PCMCIA cards may still cause that module to be loaded via udev. Or in the case of ipv6, get loaded as a dependency on some other module and hence still loads at boot even if blacklisted in [[rc.conf]].<br />
<br />
Alternative mechanism for blacklisting modules is to alias them in /etc/modprobe.d/modprobe.conf. Like so:<br />
<br />
alias net-pf-10 off<br />
<br />
In this case "net-pf-10" was an alias for ipv6.</div>PeterLhttps://wiki.archlinux.org/index.php?title=Blacklisting&diff=128771Blacklisting2011-01-23T10:42:25Z<p>PeterL: </p>
<hr />
<div>Blacklisting when refering to Kernel modules is a mechanism to stop the kernel module loading. This is either when the associated hardware is not required to be used, or loading that module causes problems. <br />
<br />
For example there may be a two kernel modules, that if they get loaded together cause try to control the same piece of hardware resulting in a conflict.<br />
<br />
Blacklisting can be done at boot time, see [[rc.conf]]; but this only applies at boot. Devices that get installed after boot e.g. USB or PCMCIA cards may still cause that module to be loaded via udev. Or in the case of ipv6, get loaded as a dependency on some other module and hence still loads at boot even if blacklisted in [[rc.conf]].<br />
<br />
Alternative mechanism for blacklisting modules is to alias them in /etc/modprobe.d/modprobe.conf. Like so:<br />
<br />
alias net-pf-10 off<br />
<br />
In this case "net-pf-10" was an alias for ipv6.</div>PeterLhttps://wiki.archlinux.org/index.php?title=Blacklisting&diff=128769Blacklisting2011-01-23T10:34:01Z<p>PeterL: </p>
<hr />
<div>Blacklisting when refering to Kernel modules is a mechanism to stop the kernel module loading. This is either when the associated hardware is not required to be used, or loading that module causes problems. <br />
<br />
For example there may be a two kernel modules, that if they get loaded together cause try to control the same piece of hardware resulting in a conflict.<br />
<br />
Blacklisting can be done at boot time, see [[rc.conf]]; but this only applies at boot. Devices that get installed after boot e.g. USB or PCMCIA cards may still cause that module to be loaded via udev</div>PeterLhttps://wiki.archlinux.org/index.php?title=Network_configuration/Wireless&diff=128768Network configuration/Wireless2011-01-23T10:31:42Z<p>PeterL: /* prism54 */</p>
<hr />
<div>[[Category:Communication and network (English)]]<br />
[[Category:Networking (English)]]<br />
[[Category:HOWTOs (English)]]<br />
{{i18n|Wireless_Setup}}<br />
Configuring wireless is a two-part process; the first part is to identify and ensure the correct driver for your wireless device is installed, (they are available on the installation media, so make sure you install them) and to configure the interface. The second is choosing a method of managing wireless connections. This article covers both parts, and provides additional links to wireless management tools.<br />
<br />
'''About new Arch systems:''' The wireless drivers and tools are available during Arch set-up under the ''base-devel'' category. Be sure to install the proper driver for your card. Udev will usually load the appropriate module, thereby creating the wireless interface, in the initial live system of the installer, as well as the newly installed system on your hard drive. If you are configuring your wireless functionality after, and not during, Arch installation, simply ensure the required packages are installed with pacman, (driver, firmware if needed, wireless_tools, wpa_supplicant, etc.) and follow the guidelines below.<br />
<br />
== Part I: Identify Card/Install Driver ==<br />
<br />
=== Identify and Discover if Supported ===<br />
<br />
First you will need to check and see if the Linux kernel has support for your card or if a user-space driver is available for it.<br />
<br />
; Identify your card<br />
<br />
:* You can find your card type by running <br />
lspci | grep -i net<br />
from the command line.<br />
:* Or, if you have a USB device, run<br />
lsusb<br />
<br />
{{Note| The internal wifi card in some laptops can actually be usb device, so make sure you check both commands.}}<br />
<br />
; Discover if card is supported<br />
<br />
:* The [https://help.ubuntu.com/community/WifiDocs/WirelessCardsSupported Ubuntu Wiki] has a good list of wireless cards and whether or not they are supported either in the Linux kernel or by a user-space driver (includes driver name).<br />
:* [http://linux-wless.passys.nl/ Linux Wireless Support] and The Linux Questions' [http://www.linuxquestions.org/hcl/index.php?cat=10 Hardware Compatibility List] (HCL) also have a good database of kernel-friendly hardware. <br />
:* The [http://wireless.kernel.org/en/users/Devices kernel page] additionaly has a matrix of supported hardware.<br />
<br />
; If your card isn't listed<br />
<br />
:* If your wireless hardware isn't listed above, likely it is supported only under Windows (some Broadcom, 3com, etc). For these you will need to use [http://ndiswrapper.sourceforge.net/wiki/index.php/List ndiswrapper]. Ndiswrapper is a wrapper script that allows you to use some Windows drivers in Linux. See the compatibility list [http://ndiswrapper.sourceforge.net/mediawiki/index.php/List here]. You will need the {{Filename|.inf}} and {{Filename|.sys}} files from your Windows install. If you have a newer card, or more exotic card, you might want to look up your exact model name and 'linux' and search the internet before doing this step.<br />
<br />
===How it works===<br />
The default Arch kernel is ''modular'', meaning many of the drivers for machine hardware reside on the hard drive and are available as ''modules''. At boot, udev takes an inventory of your hardware. Udev will load appropriate modules (drivers) for your corresponding hardware, and the driver, in turn, will allow creation of a kernel ''interface''. <br />
<br />
The interface name for different drivers and chipsets will vary. Some examples are wlan0, eth1, and ath0.<br />
<br />
*Note: Udev is not perfect. If the proper module is not loaded by udev on boot, simply modprobe it and add the module name to etc/rc.conf on the '''MODULES=''' line. Note also that udev may occasionally load more than one driver for a device, and the resulting conflict will prevent successful configuration. Be sure to blacklist the unwanted module on the '''MODULES=''' line by prefixing it with a bang (!).<br />
<br />
===Installation===<br />
<br />
====If you have wired internet available====<br />
If you have wired ethernet available, and are simply adding wireless functionality to an existing system, and did not include wireless_tools during initial installation, use pacman to install:<br />
# pacman -S wireless_tools<br />
The drivers' corresponding package names are all highlighted in '''bold''' on this page. The packages can be installed during initial package selection on the Arch installation media and can also be installed later with pacman, e.g.:<br />
# pacman -S madwifi<br />
<br />
====If you have only wireless internet available====<br />
The '''wireless_tools''' package is now available as part of the base system and is also on the live installation media (CD/USB stick image) under the '''base-devel''' category. <br />
<br />
You cannot initialize wireless hardware without these user-space tools, so ensure they are installed from the installer media, (during package selection), especially if you have no means of networking other than wirelessly. Otherwise, you will be stuck in a recursion when you reboot your newly installed Arch system; you will need wireless_tools and drivers, but in order to get them, you will need wireless_tools and drivers.<br />
<br />
===Drivers and firmware===<br />
Methods and procedures for installing drivers for various chip-sets are covered below. In addition, certain chip-sets require the installation of corresponding ''firmware'' (also covered below).<br />
<br />
====wlan-ng (obsolete)====<br />
<br />
Packages: '''wlan-ng26-utils'''<br />
<br />
This driver supports PRISM based cards, which are hard to find now. The PRISM card is an IEEE 802.11 compliant 2.4 GHz DSSS WLAN network interface card that uses the Intersil PRISM chip-set for its radio functions and the AMD PCNet-Mobile chip (AM79C930) for its Media Access Controller (MAC) function. The supported adapters can be found from here: http://www.linux-wlan.org/docs/wlan_adapters.html.gz<br />
<br />
For wlan-ng you do not need the wireless_tools package as mentioned above. Instead you will need to learn the tools in the wlan-ng26-utils package: '''wlancfg and wlanctl-ng'''.<br />
<br />
See http://www.linux-wlan.org/<br />
<br />
====rt2860 and rt2870====<br />
In kernel since 2.6.29 and requires no extra packages. It can be configured using the standard wpa_supplicant and iwconfig tools. Unfortunately this does not go for Arch. In order to get it to work, disabling the following modules has proven to be successful:<br />
<br />
rt2800pci rt61pci rt2x00pci rt2800usb rt2800lib rt2x00usb rt2x00lib<br />
<br />
It has a wide range of options that can be configured with iwpriv. These are documented in the [http://www.ralinktech.com/ralink/Home/Support/Linux.html source tarballs] available from Ralink<br />
<br />
For rt2870sta, also see [[Rt2870]]<br />
<br />
====w322u====<br />
Treat this Tenda card as an rt2870sta. See: [[Rt2870]]<br />
<br />
====rtl8180====<br />
Realtek rtl8180 PCI/Cardbus 802.11b now fully supported in the kernel. It can be configured using the standard wpa_supplicant and iwconfig tools.<br />
<br />
====rtl8192e====<br />
<br />
The driver is part of the current kernel package. It can be configured using the standard wpa_supplicant and iwconfig tools.<br />
<br />
====rtl8192s====<br />
<br />
The driver is part of the current kernel package. Firmware may need to be added manually if /lib/firmware/RTL8192SU/rtl8192sfw.bin does not exist. (dmesg will report ''"rtl819xU:FirmwareRequest92S(): failed"'' if the firmware is missing)<br />
<br />
To download and install firmware:<br />
<pre>$ wget http://launchpadlibrarian.net/33927923/rtl8192se_linux_2.6.0010.1012.2009.tar.gz<br />
# mkdir /lib/firmware/RTL8192SU<br />
# tar -xzOf rtl8192se_linux_2.6.0010.1012.2009.tar.gz \<br />
rtl8192se_linux_2.6.0010.1012.2009/firmware/RTL8192SE/rtl8192sfw.bin > \<br />
/lib/firmware/RTL8192SU/rtl8192sfw.bin</pre><br />
<br />
Note: An alternate version of the firmware may be found [http://launchpadlibrarian.net/37387612/rtl8192sfw.bin.gz here], but this version may cause dropped connections.<br />
<br />
Note: [[wicd]] may cause excessive dropped connections with this driver, while [[NetworkManager]] appears to work better.<br />
<br />
====rt2x00====<br />
Unified driver for Ralink chip-sets (replaces rt2500,rt61,rt73 etc). In kernel since 2.6.24, some devices require extra firmware. It can be configured using the standard wpa_supplicant and iwconfig tools.<br />
<br />
Some chips require a firmware file, which can be installed as follows, depending on the chip-set:<br />
<pre>pacman -S linux-firmware</pre><br />
<br />
See: [[Using the new rt2x00 beta driver]]<br />
<br />
====rt2500, rt61, rt73 (obsolete)====<br />
For Ralink <br />
* PCI/PCMCIA based rt2500 series chip-sets.<br />
* PCI/PCMCIA based rt61 series chip-sets<br />
* USB based rt73 series chip-sets. <br />
<br />
Drivers are now '''obsolete''' and '''unsupported'''. The rt2x00 driver family is stable and to be used instead.<br />
<br />
Support standard iwconfig tools for unencrypted and WEP connections, although it can be quite sensitive to the order of commands.<br />
The driver does support WPA (using hardware encryption), but in a non-standard way. wpa_supplicant appears to include special support for this driver, and it is also possible to negotiate a WPA connection manually using iwpriv commands.<br />
See [http://rt2400.cvs.sourceforge.net/*checkout*/rt2400/source/rt2500/Module/iwpriv_usage.txt these instructions] for details.<br />
<br />
====madwifi-ng====<br />
Package: '''madwifi''' (and optionaly '''madwifi-utils''')<br />
<br />
The module is called <tt>ath_pci</tt>.<br />
<br />
Note there are newer modules maintained by the MadWifi team:<br />
* [[#ath5k|ath5k]] will eventually phase out ath_pci. Currently a better choice for some chipsets.<br />
* [[#ath9k|ath9k]] is the new, official, superior driver for newer Atheros hardware (see below).<br />
<br />
modprobe ath_pci<br />
for the older driver, or:<br />
modprobe ath5k<br />
for the development version. Note that not all cards work with ath5k yet.<br />
<br />
If using ath_pci, you may need to blacklist ath5k by adding it to the MODULES=array in /etc/rc.conf, and subsequently prefixing it with a bang (!):<br />
MODULES=(!ath5k forcedeth snd_intel8x0 ... ...)<br />
<br />
Some users '''may need''' to use the 'countrycode' option when loading the MadWifi driver in order to use channels and transmit power settings that are legal in their country/region. In the Netherlands, for example, you would load the module like this:<br />
<br />
modprobe ath_pci countrycode=528<br />
<br />
You can verify the settings with the <tt>iwlist</tt> command. See <tt>man iwlist</tt> and the [http://madwifi-project.org/wiki/UserDocs/CountryCode CountryCode page on the MadWifi wiki]. To have this setting automatically applied during boot, add the following to <tt>/etc/modprobe.d/modprobe.conf</tt>:<br />
<br />
{{Note| The new module-init-tools 3.8 package changes the location of the configuration file: /etc/modprobe.conf is no longer read, instead /etc/modprobe.d/modprobe.conf is used. [http://www.archlinux.org/news/450/ link]}}<br />
<br />
options ath_pci countrycode=528<br />
<br />
{{Note|A user had to remove the countrycode option completely or else the ath0 device was not created (kernel 2.6.21).}}<br />
<br />
====ath5k====<br />
ath5k is the preferred driver for AR5xxx chipsets including those which are already working with madwifi-ng and for some chipsets older than AR5xxx. <br />
<br />
If ath5k is conflicting with ath_pci on your system, blacklist (and unload using rmmod or reboot) the following drivers...<br />
MODULES=(<br />
...<br />
!ath_hal !ath_pci !ath_rate_amrr !ath_rate_onoe !ath_rate_sample !wlan !wlan_acl !wlan_ccmp !wlan_scan_ap !wlan_scan_sta !wlan_tkip !wlan_wep !wlan_xauth<br />
...<br />
)<br />
<br />
then modprobe ath5k manualy or reboot. wlan0 (or wlanX) in sta mode should spawn and become ready to use.<br />
<br />
Info:<br />
* http://wireless.kernel.org/en/users/Drivers/ath5k<br />
* http://wiki.debian.org/ath5k<br />
<br />
{{Note|Some laptop have problem of Wireless LED indicator flickers red and blue. To solve this problem do :<br />
echo none > "/sys/class/leds/ath5k-phy0::tx/trigger"<br />
echo none > "/sys/class/leds/ath5k-phy0::rx/trigger"<br />
For alternative look {{[https://bugzilla.redhat.com/show_bug.cgi?id=618232 here]}}}}<br />
<br />
====ath9k====<br />
ath9k is Atheros' officially supported driver for the newer 11n chip-sets. All of the chips with 11n capabilities are supported, with a maximum throughput around 180 Mbps. To see a complete list of supported hardware, check this [http://wireless.kernel.org/en/users/Drivers/ath9k page].<br />
<br />
Working modes: Station, AP and Adhoc.<br />
<br />
ath9k has been part of the kernel as of 2.6.27. Support seems acceptable as of 2.6.32 (see [http://linuxwireless.org/en/users/Drivers/ath9k/bugs#Minimal_kernel_requirements details on linuxwireless.org]). (In the unlikely event that you have stability issues that trouble you, you could try using the [http://wireless.kernel.org/en/users/Download compat-wireless] package.<br />
An [https://lists.ath9k.org/mailman/listinfo/ath9k-devel ath9k mailing list] exists for support and development related discussions.)<br />
<br />
Info:<br />
* http://wireless.kernel.org/en/users/Drivers/ath9k<br />
* http://wiki.debian.org/ath9k<br />
<br />
====ath9k_htc====<br />
ath9k_htc is Atheros' officially supported driver for 11n USB devices. Station and Ad-Hoc modes are supported. Since 2.6.35, the driver has been included in the kernel. For more information, see http://wireless.kernel.org/en/users/Drivers/ath9k_htc .<br />
<br />
====ipw2100 and ipw2200====<br />
Fully supported in the kernel, but requires additional firmware. It can be configured using the standard wpa_supplicant and iwconfig tools.<br />
<br />
Depending on which of the chips you have, use either:<br />
<br />
'''ipw2100-fw'''<br />
pacman -S ipw2100-fw<br />
<br />
or:<br />
<br />
'''ipw2200-fw'''<br />
pacman -S ipw2200-fw<br />
<br />
If installing after initial Arch installation, the module may need to be reloaded for the firmware to be loaded; run the following as root:<br />
<br />
rmmod ipw2200<br />
modprobe ipw2200<br />
<br />
=====Enabling the radiotap interface=====<br />
Launch the following (as root):<br />
<br />
rmmod ipw2200<br />
modprobe ipw2200 rtap_iface=1<br />
<br />
=====Enabling the LED=====<br />
Most laptops will have a front LED to indicate when the wireless is connected (or not). Run the following (as root) to enable this feature:<br />
<br />
echo "options ipw2200 led=1" >> /etc/modprobe.d/ipw2200.conf<br />
<br />
or if using sudo:<br />
<br />
echo "options ipw2200 led=1" | sudo tee -a /etc/modprobe.d/ipw2200.conf<br />
<br />
====iwl3945, iwl4965 and iwl5000-series====<br />
'''I'''ntel's open source '''W'''iFi drivers for '''L'''inux (See [http://intellinuxwireless.org iwlwifi]) will work for both the 3945 and 4965 chipsets since kernel v2.6.24. And iwl5000-series chipsets (including 5100BG, 5100ABG, 5100AGN, 5300AGN and 5350AGN) module has been supported since '''kernel 2.6.27''', by the intree driver '''iwlagn'''.<br />
<br />
=====Installing Firmware (Microcode)=====<br />
'''Important:''' Installing these firmware packages is not required since the 2.6.34 kernel<br />
update, when the firmware files were moved to the linux-firmware package:<br />
<br />
# pacman -S linux-firmware<br />
<br />
If you need wireless connectivity to access pacman's repositories, the firmware files are also available direct from Intel. See [http://intellinuxwireless.org/?n=downloads this ] page, select and download the archive.<br />
$ wget http://intellinuxwireless.org/iwlwifi/downloads/iwlwifi-XXXX-ucode-XXX.XX.X.XX.tgz<br />
<br />
After downloading, you must extract and copy the *.ucode file to the firmware directory, commonly /lib/firmware<br />
# tar zxvf iwlwifi-XXXX-ucode-XXX.XX.X.XX.tgz<br />
# cd iwlwifi-XXXX-ucode-XXX.XX.X.XX/<br />
# cp iwlwifi-XXXX-X.ucode /lib/firmware/<br />
<br />
=====Loading the Driver=====<br />
If MOD_AUTOLOAD is set to yes in /etc/rc.conf (it is by default) that should be all that is required. Simply check for the presence of the drivers by running '''ifconfig -a''' from a terminal. There should be a listing for wlan0.<br />
<br />
Do this ONLY if MOD_AUTOLOAD is not set: to manually load the driver at startup, edit <tt>/etc/rc.conf</tt> as root and add '''iwl3945''' or '''iwl4965''' respectively to the MODULES array. For example:<br />
<br />
MODULES=( ... b44 mii '''iwl3945''' snd-mixer-oss ...)<br />
<br />
The drivers should now load after a reboot, and running '''ifconfig -a''' from a terminal should report '''wlan0''' as a new network interface.<br />
<br />
=====Disabling LED blink=====<br />
<br />
The default settings on the module are to have the LED blink on activity. Some people like myself find this extremely annoying. To have the LED on solid when wifi is active:<br />
<br />
# echo "options iwlcore led_mode=1" >> /etc/modprobe.d/modprobe.conf<br />
# rmmod iwlagn<br />
# rmmod iwlcore<br />
# modprobe iwlcore<br />
# modprobe iwlagn<br />
<br />
=====Other Notes=====<br />
* The windows NETw4x32 driver can be used with ndiswrapper as an alternative to the iwl3945 and ipw3945 drivers<br />
* In some cases (specifically a [[Dell Latitude D620]] with Arch 2008.06, though it could happen elsewhere) after installation you may have both iwl3945 and ipw3945 in your <tt>MODULES=()</tt> section of rc.conf. The card will not work with both modules loaded, so you will have to ! out the ipw3945 module and then reboot or remove the module manually before you can use your wireless card.<br />
* By default iwl3945 is configured to only work with networks on channels 1-11. Higher ranges are not allowed in some parts of the world (US). In the EU however channels 12 and 13 are used quite common. To make iwl3945 scan for all channels, add "options cfg80211 ieee80211_regdom=EU" to /etc/modprobe.d/modprobe.conf. With "iwlist f" you can check which channels are allowed.<br />
* If you want to enable more channels on Intel Wifi 5100 (and quite possible other cards too) you can do that with the crda package. After install, edit /etc/conf.d/wireless-regdom and uncomment the line where your country code is found. Add wireless-regdom to your DAEMONS in rc.conf and restart (which is the easiest thing to do). You should now, when writing sudo iwlist wlan0 channel, have access to more channels (depending on your location).<br />
* The wifi power management can be enabled by adding:<br />
iwconfig wlan0(change as appropriate) power on<br />
to /etc/rc.local.<br />
<br />
====ipw3945 (obsolete)====<br />
{{Note| ''The ipw3945 driver is no longer actively developed, and the iwlwifi driver (described above) should work perfectly, but may conflict with the former one. Therefore only one of them should be installed. If you choose to use the iwlwifi driver, the '''ipw3945-ucode''' package is still required.''}}<br />
# pacman -S ipw3945 ipw3945-ucode ipw3945d<br />
To initialize the driver on startup, edit <tt>/etc/rc.conf</tt> as root and add '''ipw3945''' to the MODULES array and '''ipw3945d''' to the DAEMONS array. For example:<br />
<br />
MODULES=(... mii '''ipw3945''' snd-mixer-oss ...)<br />
<br />
DAEMONS=(syslog-ng '''ipw3945d''' network ...)<br />
<br />
'''Note:''' The '''ipw3945d''' daemon ''must'' be inserted BEFORE all other network daemons in the array.<br />
<br />
====orinoco====<br />
This should be part of the kernel package and be installed already.<br />
<br />
Note: Some orinoco chipsets are Hermes I/II. You can use http://aur.archlinux.org/packages.php?ID=9637 to replace the orinoco driver and gain WPA support. See http://ubuntuforums.org/showthread.php?p=2154534#post2154534 for more information.<br />
<br />
To use the driver, blacklist orinoco_cs in rc.conf (!orinoco_cs in the MODULES array) and add wlags49_h1_cs. Example:<br />
MODULES=(!eepro100 ''!orinoco_cs'' '''wlags49_h1_cs''')<br />
<br />
====ndiswrapper====<br />
Ndiswrapper is not a real driver, but you can use it when there are no native Linux kernel drivers for your wireless chips. So it is very useful in some situations. To use it you need the *.inf file from your Windows driver (the *.sys file must also be present in the same directory). Be sure to use drivers appropriate to your architecture (i.e. 32/64bit). If you need to extract these files from an *.exe file, you can use either cabextract or wine. Ndiswrapper is included on the Arch Linux installation CD.<br />
<br />
Follow these steps to configure ndiswrapper.<br />
<pre><br />
#Install the driver to /etc/ndiswrapper/*<br />
ndiswrapper -i filename.inf<br />
#List all installed driver for ndiswrapper<br />
ndiswrapper -l<br />
#Write configuration file in /etc/modprobe.d/ndiswrapper.conf<br />
ndiswrapper -m<br />
depmod -a</pre><br />
<br />
Now the ndiswrapper install is almost finished; you just have to update /etc/rc.conf to load the module at boot (below is a sample of my config; yours might look slightly different):<br />
<br />
<pre>MODULES=(ndiswrapper snd-intel8x0 !usbserial)</pre><br />
<br />
The important part is making sure that ndiswrapper exists on this line, so just add it alongside the other modules. It would be best to test that ndiswrapper will load now, so:<br />
<br />
<pre>modprobe ndiswrapper<br />
iwconfig</pre><br />
<br />
and wlan0 should exist. Check this page if you're having problems:<br />
[http://ndiswrapper.sourceforge.net/joomla/index.php?/component/option,com_openwiki/Itemid,33/id,installation/ Ndiswrapper installation wiki].<br />
<br />
====prism54====<br />
Download the firmware driver for your appropriate card from [http://linuxwireless.org/en/users/Drivers/p54 this site]. Rename the firmware file to 'isl3890'.<br />
If nonexistent, create the directory /lib/firmware and place the file 'isl3890' in it. This should do the trick. [http://bbs.archlinux.org/viewtopic.php?t=16569&start=0&postdays=0&postorder=asc&highlight=siocsifflags+such+file++directory]<br />
<br />
If that did not work, try this:<br />
<br />
*Reload the prism module (modprobe p54usb or modprobe p54pci, depending on your hardware)<br />
alternatively remove your wifi card and then reconnect it<br />
*Use the "dmesg" command, and look at the end of the output it prints out.<br />
Look for a section looking like this: <br />
firmware: requesting '''isl3887usb_bare'''<br />
p54: LM86 firmware<br />
p54: FW rev 2.5.8.0 - Softmac protocol 3.0<br />
and try renaming the firmware file to the name corresponding to the part bolded here.<br />
<br />
If you get message <br />
SIOCSIFFLAGS: Operation not permitted<br />
when performing 'ifconfig wlan0 up' OR <br />
prism54: Your card/socket may be faulty, or IRQ line too busy :(<br />
appears in dmesg this may be because you have both the deprecated kernel module "prism54" and the newer kernel module "p54pci" or "p54usb" loaded at the same time and they are fighting over ownership of the IRQ. Use command "lsmod | grep prism54" to see if indeed the deprecated module is being loaded. If so you need to stop "prism54" loading by [[blacklisting]] it (there are several ways to do this which are described elsewhere). Once blacklisted, you may find you have to rename the firmware as prism54 and p54pci/p54usb look for different firmware filenames (i.e. recheck the dmesg output after performing ifconfig wlan0 up).<br />
<br />
====ACX100/111====<br />
packages: tiacx tiacx-firmware<br />
<br />
The driver should tell you which firmware it needs; check /var/log/messages.log or use the dmesg command.<br />
<br />
Link the appropriate firmware to '/lib/firmware':<br />
ln -s /usr/share/tiacx/acx111_2.3.1.31/tiacx111c16 /lib/firmware<br />
<br />
For another way to determine which firmware revision number to use, see the [http://acx100.sourceforge.net/wiki/Firmware "Which firmware" section] of the acx100.sourceforge wiki. For ACX100, you can follow the links provided there, to a table of card model number vs. "firmware files known to work"; you can figure out the rev. number you need, by looking at the suffix there. E.g. a dlink_dwl650+ uses "1.9.8.b", in which case you'd do this:<br />
ln -s /usr/share/tiacx/acx100_1.9.8.b/* /lib/firmware<br />
<br />
If you find that the driver is spamming your kernel log, for example because you're running Kismet with channel-hopping, you could put this in /etc/modprobe.d/modprobe.conf:<br />
options acx debug=0<br />
<br />
{{Note|The open-source acx driver does not support WPA/RSN encryption. Ndiswrapper will have to be used with the windows driver to enable the enhanced encryption. See ndiswrapper, this page, for more details.}}<br />
<br />
==== b43 ====<br />
<br />
This driver is the successor to the bcm43xx driver, and is included in kernel from 2.6.24 on.<br />
<br />
If you haven't discovered you card make yet, run:<br />
<br />
lspci | grep Network<br />
<br />
To see if your Broadcom card is supported and to identify the proper module, look [http://wireless.kernel.org/en/users/Drivers/b43#Known_PCI_devices here]. For known card models in various computers, look [http://linuxwireless.org/en/users/Drivers/b43/devices here]. Define the module to use in {{Filename|/etc/rc.conf}} and blacklist the other module to prevent possible problems or confusion.:<br />
<br />
MODULES=(... !b43legacy b43) # or<br />
MODULES=(... !b43 b43legacy)<br />
<br />
Install the corresponding Broadcom 43xx firmware package for your hardware. The packages are on the [[AUR]]:<br />
<br />
b43-firmware <br />
b43-firmware-legacy # for older cards<br />
<br />
Restart, and configure your device as normal. For more detailed information and installation manuals of b43 driver see [http://wireless.kernel.org/en/users/Drivers/b43 b43 homepage]<br />
<br />
Create a new folder to your home (wifi or any other name)<br />
<br />
sudo pacman -S b43-fwcutter<br />
export FIRMWARE_INSTALL_DIR="/lib/firmware"<br />
wget http://downloads.openwrt.org/sources/broadcom-wl-4.178.10.4.tar.bz2<br />
tar xjf broadcom-wl-4.178.10.4.tar.bz2<br />
cd broadcom-wl-4.178.10.4/linux<br />
sudo b43-fwcutter -w "$FIRMWARE_INSTALL_DIR" wl_apsta.o<br />
<br />
reboot your computer<br />
<br />
Note: those steps were taken from<br />
<br />
[http://wireless.kernel.org/en/users/Drivers/b43/ b43]<br />
<br />
====broadcom-wl====<br />
Some recent Broadcom 43xx cards not supported by bcm43xx or b43. Not just for some 43XX cards. See the [[Broadcom_BCM43XX|Broadcom 43XX wiki page]]. It is available in [http://aur.archlinux.org/packages.php?ID=19514 AUR]. These chipsets are used in most Dell laptops, among others.<br />
<br />
====brcm80211====<br />
[http://wireless.kernel.org/en/users/Drivers/brcm80211 brcm80211] is the new open-source driver for a few modern Broadcom chips. It has been in the kernel since 2.6.37. Here is a current list of supported chips:<br />
{| border="1"<br />
! Name !! PCI-ID<br />
|-<br />
| BCM4313 || 0x4727<br />
|-<br />
| BCM43224 || 0x4353<br />
|-<br />
| BCM43225 || 0x4357<br />
|}<br />
<br />
=====Troubleshooting=====<br />
======Lock-Ups======<br />
There is a common problem with some chips running on multi-core systems where the system will lock up while running 'iwlist scan' (or in the scanning process using a wireless client). The only known solution for this (so far) is to run your system with only one core. This can be done by appending 'maxcpus=1' to your kernel line in GRUB's {{Filename|menu.lst}} (or the equivalent for whatever bootloader you use).<br />
<br />
====rtl8187====<br />
See: [[Rtl8187_wireless|rtl8187]]<br />
<br />
====zd1211rw====<br />
[http://zd1211.wiki.sourceforge.net/ zd1211rw] is a driver for the ZyDAS ZD1211 802.11b/g USB WLAN chipset and it is included in recent versions of the Linux kernel. See [http://www.linuxwireless.org/en/users/Drivers/zd1211rw/devices] for a list of supported devices. You only need to install the firmware for the device: <pre>pacman -S zd1211-firmware</pre><br />
<br />
====carl9170====<br />
[http://wireless.kernel.org/en/users/Drivers/carl9170/ carl9170] is the 802.11n USB driver with GPLv2 firmware for Atheros USB AR9170 devices. It support these [http://wireless.kernel.org/en/users/Drivers/carl9170#available_devices devices]. The firmware is available in [https://aur.archlinux.org/packages.php?ID=44102/ AUR]. The driver is part of '''kernel 2.6.37'''. For older kernel use the driver package from [https://aur.archlinux.org/packages.php?ID=44100/ AUR]. <br />
In addition, to block loading of the older ar9170usb driver module, add !arusb_lnx and !ar9170usb to MODULES() in /etc/rc.conf:<br />
<pre>MODULES=(... !arusb_lnx !ar9170usb ...)</pre><br />
<br />
===Test installation===<br />
After loading your driver run<br />
iwconfig<br />
to ensure a wireless interface (wlan''x'', eth''x'', ath''x'') is created.<br />
<br />
If no such interface is visible, modprobing it might work. To start your driver, use the '''rmmod''' and '''modprobe''' commands (if rmmod fails, continue with modprobe).<br />
<br />
Example: if your driver is called "driverXXX", you would run the following commands:<br />
# rmmod driverXXX<br />
# modprobe driverXXX<br />
<br />
Bring the interface up with <code>ifconfig <interface> up</code>. e.g. assuming the interface is <code>wlan0</code>:<br />
# ifconfig wlan0 up<br />
If you get this error message: <code>SIOCSIFFLAGS: No such file or directory</code> it most certainly means your wireless chipset requires a firmware to function, which you need to install as explained above.<br />
<br />
==Part II: Wireless management==<br />
Assuming that your drivers are installed and working properly, you will need to choose a method for managing your wireless connections. The following subsections will help you decide the best way to do just that.<br />
<br />
Procedure and tools required will depend on several factors:<br />
* The desired nature of configuration management; from a completely manual command line setup procedure repeated at each boot to a software-managed, automated solution<br />
* The encryption type (or lack thereof) which protects the wireless network<br />
* The need for network profiles, if the computer will frequently change networks (such as a laptop)<br />
<br />
===Management methods===<br />
This table shows the different methods that can be used to activate and manage a wireless network connection, depending on the encryption and management types, and the various tools that are required. Although there may be other possibilities, these are the most frequently used:<br />
{| border="1"<br />
! Management || No encryption/WEP || WPA/WPA2 PSK<br />
|-<br />
| Manual, need to repeat at each computer reboot || <code>ifconfig + iwconfig + dhcpcd/ifconfig</code> || <code>ifconfig + iwconfig + wpa_supplicant + dhcpcd/ifconfig</code><br />
|-<br />
| Automatically managed, centralized without network profile support || define interface in <code>/etc/rc.conf</code> || not covered<br />
|-<br />
| Automatically managed, with network profiles support || colspan="2" align="center" | <code>Netcfg, newlan (AUR), wicd, NetworkManager, etc…</code><br />
|}<br />
<br />
More choice guide: <br />
<br />
{| border="1"<br />
! - || Netcfg+Newlan(AUR) || Wicd ||NetworkManager+network-manager-applet<br />
|-<br />
| auto connect at boot || with net-profiles daemon config in rc.conf || yes || yes<br />
|-<br />
| auto connect if dropped <br>or changed location || with net-auto-wireless daemon config in rc.conf || yes || yes<br />
|-<br />
| support 3G Modem || || || yes<br />
|-<br />
| GUI (proposes to manage and connect/disconnect<br> profiles from a systray icon. <br>Automatic wireless detection is also availabl) || with ArchAssitant || yes || yes<br />
|-<br />
| console tools || with wifi-select (AUR) || wicd-curses(part of wicd package) || nmcli<br />
|-<br />
| connect speed || slow || || fast<br />
|}<br />
<br />
Whatever your choice, you should try to connect using the manual method first. This will help you understand the different steps that are required and debug them in case a problem arose. Another tip: if possible (e.g. if you manage your wifi access point), try connecting with no encryption, to check everything works. Then try using encryption, either WEP (simpler to configure -- but crackable in a matter of minutes, so it's hardly more secure than an unencrypted connection) or WPA.<br />
<br />
When it comes to easy of use, NetworkManager (with Gnome network-manager-applet) and wicd have good GUIs and can provide a list of available networks to connect, they prompt for passwords, which is straightforward and highly recommended. (Note Gnome network-manager-applet also works under xfce4 if you install xfce4-xfapplet-plugin first, also there are applet available for KDE.) <br />
<br />
====Manual setup====<br />
The programs provided by the package '''wireless_tools''' are the basic set of tools to set up a wireless network. Moreover, if you use WPA/WPA2 encryption, you will need the package '''wpa_supplicant'''. These powerful userspace console tools work extremely well and allow complete, manual control from the shell.<br />
<br />
These examples assume your wireless device is <code>wlan0</code>. Replace <code>wlan0</code> with the appropriate device name.<br />
{{Note| Depending on your hardware and encryption type, some of these steps may not be necessary. Some cards are known to require interface activation and/or access point scanning before being associated to an access point and being given an IP address. Some experimentation may be required. For instance, WPA/WPA2 users may directly try to activate their wireless network from step 3.}}<br />
<br />
'''Step 0.''' ''(Optional, may be required)'' At this step you may need to set the proper operating mode of the wireless card. More specifically, if you're going to connect an ad-hoc network, you might need to set the operating mode to ''ad-hoc:''<br />
# iwconfig wlan0 mode ad-hoc<br />
<br />
{{Note| Ideally, you should a priori know, which type of network you are going to connect. If you don't, scan the network as described in step 2 below, then, if necessary, return back to this step and change the mode. Also, please, bear in mind that changing the operating mode might require the wlan interface to be ''down'' (<code>ifconfig wlan0 down</code>).}}<br />
<br />
'''Step 1.''' ''(Also optional, may be required)'' Some cards require that the kernel interface be activated before you can use the wireless_tools:<br />
# ifconfig wlan0 up<br />
<br />
'''Step 2.''' See what access points are available:<br />
# iwlist wlan0 scan<br />
<br />
{{Note| If it displays "''Interface does not support scanning''" then you probably forgot to install the firmware. You can also try bringing up the interface first as shown in point 1.}}<br />
<br />
'''Step 3.''' Depending on the encryption, you need to associate your wireless device with the access point to use and pass the encryption key.<br />
<br />
Assuming you want to use the ESSID named <code>MyEssid</code>:<br />
* ''No encryption''<br />
# iwconfig wlan0 essid "MyEssid"<br />
* ''WEP''<br />
using an hexadecimal key:<br />
# iwconfig wlan0 essid "MyEssid" key 1234567890<br />
using an ascii key:<br />
# iwconfig wlan0 essid "MyEssid" key s:asciikey<br />
* ''WPA/WPA2''<br />
<br />
You need to edit the <code>/etc/wpa_supplicant.conf</code> file as described in [[WPA_Supplicant]]. Then, issue this command:<br />
# wpa_supplicant -B -Dwext -i wlan0 -c /etc/wpa_supplicant.conf<br />
<br />
This is assuming your device uses the <code>wext</code> driver. If this does not work, you may need to adjust these options. Check [[WPA_Supplicant]] for more information and troubleshooting.<br />
<br />
Regardless of the method used, you can check if you have associated successfully as follows:<br />
# iwconfig wlan0<br />
<br />
'''Step 4.''' Finally, provide an IP address to the network interface. Simple examples are:<br />
# dhcpcd wlan0<br />
for DHCP, or<br />
# ifconfig wlan0 192.168.0.2<br />
# route add default gw 192.168.0.1<br />
for static IP.<br />
<br />
Note: If you get an timeout error due to a ''waiting for carrier'' problem then you might have to set channel mode to auto for the specific device.<br />
<br />
# iwconfig wlan0 channel auto <br />
<br />
{{Note| Although the manual configuration method will help troubleshoot wireless problems, you will have to retype every command each time you reboot.}}<br />
<br />
====Automatic setup====<br />
There are many solutions to choose from, but remember that all of them are mutually exclusive; you should not run two daemons simultaneously.<br />
<br />
=====Standard network daemon=====<br />
{{Note| This method and configuration examples are only valid for unencrypted or WEP-encrypted networks, which are particularly unsecure. To use WPA/WPA2, you will need to use other solutions such as '''[[netcfg]]''' or '''[[wicd]]'''. Also, avoid mixing these methods as they may create a conflict and prevent the wireless card from functioning.}}<br />
<br />
* The '''/etc/rc.conf''' file is sourced by the network script. Therefore, you may define and configure a simple wireless setup within /etc/rc.conf for a centralized approach with '''wlan_<interface>="<interface> essid <essid>"''' and '''INTERFACES=(<interface1> <interface2>)'''. The name of the network goes in place of '''MyEssid'''.<br />
<br />
For example:<br />
# /etc/rc.conf<br />
eth0="dhcp"<br />
wlan0="dhcp"<br />
wlan_wlan0="wlan0 essid MyEssid" # Unencrypted<br />
#wlan_wlan0="wlan0 essid MyEssid key 1234567890" # hex WEP key<br />
#wlan_wlan0="wlan0 essid MyEssid key s:asciikey" # ascii WEP key<br />
INTERFACES=(eth0 wlan0)<br />
<br />
Not all wireless cards are <code>wlan0</code>. Determine your wireless interface with ifconfig -a. <br />
Atheros-based cards, for example, are typically <code>ath0</code>, so change <code>wlan_wlan0</code> to:<br />
wlan_ath0="ath0 essid MyEssid key 12345678" <br />
Also define ath0 in the INTERFACES=line.)<br />
<br />
* Alternatively, you may define wlan_<interface> within /etc/conf.d/wireless, (which is also sourced by the network script), for a de-centralized approach:<br />
# /etc/conf.d/wireless<br />
wlan_wlan0="wlan0 essid MyEssid"<br />
<br />
These solutions are limited for a laptop which is always on the move. It would be good to have multiple [[Network Profiles]] and be able to easily switch from one to another. That is the aim of network managers, such as netcfg.<br />
<br />
=====Netcfg=====<br />
'''netcfg''' provides a ''versatile, robust and fast'' solution to networking on Arch.<br />
<br />
It uses a profile based setup and is capable of detection and connection to a wide range of network types. This is no harder than using graphical tools. Following the directions above, you can get a list of wireless networks. Then, as with graphical tools, you will need a password.<br />
<br />
See: [[Network Profiles]], and [[Network Profiles development]]<br />
<br />
=====Netcfg Easy Wireless LAN (newlan)=====<br />
newlan is a mono console application that starts a user-friendly wizard to create netcfg profiles, it supports also wired connections.<br />
<br />
Install from [[AUR]]: http://aur.archlinux.org/packages.php?ID=33649<br />
<br />
Or use the [[AUR]] helper of your choice.<br />
<br />
newlan must be run with root privileges:<br />
# sudo newlan -n mynewprofile<br />
<br />
=====Autowifi=====<br />
<br />
{{Box|Autowifi is deprecated|Autowifi has been deprecated in favor of [[netcfg]]'s [[Netcfg#net-auto-wireless|net-auto-wireless]] mode|#DF0000|#FFDFDF}}<br />
<br />
Autowifi is a daemon that configures your wireless network automatically depending on the ESSID. Once configured, no user interaction is necessary and no GUI tools are required.<br />
<br />
See: [[Autowifi]]<br />
<br />
=====Wicd=====<br />
Wicd is a network manager that can handle both wireless and wired connections. It is written in Python and Gtk with fewer dependencies than NetworkManager, making it an ideal solution for lightweight desktop users. Wicd is now available in the extra repository for both i686 and x86_64.<br />
<br />
See: [[Wicd]]<br />
<br />
=====NetworkManager=====<br />
NetworkManager is an advanced network management tool that is enabled by default in most popular GNU/Linux distributions. In addition to managing wired connections, NetworkManager provides worry-free wireless roaming with an easy-to-use GUI program for selecting your desired network. <br />
<br />
See: [[NetworkManager]]<br />
<br />
=====Wifi Radar=====<br />
WiFi Radar is Python/PyGTK2 utility for managing wireless profiles (and ''only'' wireless). It enables you to scan for available networks and create profiles for your preferred networks.<br />
<br />
See: [[Wifi Radar]]<br />
<br />
=====Wlassistant=====<br />
Wlassistant is a very intuitive and straightforward GUI application for managing your wireless connections. <br />
<br />
Install from AUR: http://aur.archlinux.org/packages.php?ID=1726<br />
<br />
Wlassistant must be run with root privileges:<br />
# sudo wlassistant<br />
One method of using wlassistant is to configure your wireless card within /etc/rc.conf, specifying the access point you use most often. On startup, your card will automatically be configured for this ESSID, but if other wireless networks are needed/available, wlassistant can then be invoked to access them. Background the network daemon in /etc/rc.conf, by prefixing it with a @, to avoid boot delays.<br />
<br />
==See also==<br />
*[[Sharing ppp connection with wlan interface]]<br />
<br />
==External links==<br />
*[http://www.gnome.org/projects/NetworkManager/ NetworkManager] -- The official website for NetworkManager<br />
*[http://wicd.sourceforge.net/ WICD] -- The official website for WICD<br />
*[https://lists.anl.gov/mailman/listinfo/wifi-radar Wifi Radar] -- Wifi Radar information page<br />
*[http://madwifi.org/wiki/UserDocs/FirstTimeHowTo The madwifi project's method of installing] -- Recommended if you are having trouble after reading this article</div>PeterLhttps://wiki.archlinux.org/index.php?title=Blacklisting&diff=128766Blacklisting2011-01-23T10:23:46Z<p>PeterL: Created page with "Blacklisting when refering to Kernel modules is a mechanism to stop the kernel module loading. This is either when the associated hardware is not required to be used, or loading ..."</p>
<hr />
<div>Blacklisting when refering to Kernel modules is a mechanism to stop the kernel module loading. This is either when the associated hardware is not required to be used, or loading that module causes problems. <br />
<br />
For example there may be a two kernel modules, that if they get loaded together cause try to control the same piece of hardware resulting in a conflict.</div>PeterLhttps://wiki.archlinux.org/index.php?title=Network_configuration/Wireless&diff=128764Network configuration/Wireless2011-01-23T10:04:41Z<p>PeterL: /* prism54 */</p>
<hr />
<div>[[Category:Communication and network (English)]]<br />
[[Category:Networking (English)]]<br />
[[Category:HOWTOs (English)]]<br />
{{i18n|Wireless_Setup}}<br />
Configuring wireless is a two-part process; the first part is to identify and ensure the correct driver for your wireless device is installed, (they are available on the installation media, so make sure you install them) and to configure the interface. The second is choosing a method of managing wireless connections. This article covers both parts, and provides additional links to wireless management tools.<br />
<br />
'''About new Arch systems:''' The wireless drivers and tools are available during Arch set-up under the ''base-devel'' category. Be sure to install the proper driver for your card. Udev will usually load the appropriate module, thereby creating the wireless interface, in the initial live system of the installer, as well as the newly installed system on your hard drive. If you are configuring your wireless functionality after, and not during, Arch installation, simply ensure the required packages are installed with pacman, (driver, firmware if needed, wireless_tools, wpa_supplicant, etc.) and follow the guidelines below.<br />
<br />
== Part I: Identify Card/Install Driver ==<br />
<br />
=== Identify and Discover if Supported ===<br />
<br />
First you will need to check and see if the Linux kernel has support for your card or if a user-space driver is available for it.<br />
<br />
; Identify your card<br />
<br />
:* You can find your card type by running <br />
lspci | grep -i net<br />
from the command line.<br />
:* Or, if you have a USB device, run<br />
lsusb<br />
<br />
{{Note| The internal wifi card in some laptops can actually be usb device, so make sure you check both commands.}}<br />
<br />
; Discover if card is supported<br />
<br />
:* The [https://help.ubuntu.com/community/WifiDocs/WirelessCardsSupported Ubuntu Wiki] has a good list of wireless cards and whether or not they are supported either in the Linux kernel or by a user-space driver (includes driver name).<br />
:* [http://linux-wless.passys.nl/ Linux Wireless Support] and The Linux Questions' [http://www.linuxquestions.org/hcl/index.php?cat=10 Hardware Compatibility List] (HCL) also have a good database of kernel-friendly hardware. <br />
:* The [http://wireless.kernel.org/en/users/Devices kernel page] additionaly has a matrix of supported hardware.<br />
<br />
; If your card isn't listed<br />
<br />
:* If your wireless hardware isn't listed above, likely it is supported only under Windows (some Broadcom, 3com, etc). For these you will need to use [http://ndiswrapper.sourceforge.net/wiki/index.php/List ndiswrapper]. Ndiswrapper is a wrapper script that allows you to use some Windows drivers in Linux. See the compatibility list [http://ndiswrapper.sourceforge.net/mediawiki/index.php/List here]. You will need the {{Filename|.inf}} and {{Filename|.sys}} files from your Windows install. If you have a newer card, or more exotic card, you might want to look up your exact model name and 'linux' and search the internet before doing this step.<br />
<br />
===How it works===<br />
The default Arch kernel is ''modular'', meaning many of the drivers for machine hardware reside on the hard drive and are available as ''modules''. At boot, udev takes an inventory of your hardware. Udev will load appropriate modules (drivers) for your corresponding hardware, and the driver, in turn, will allow creation of a kernel ''interface''. <br />
<br />
The interface name for different drivers and chipsets will vary. Some examples are wlan0, eth1, and ath0.<br />
<br />
*Note: Udev is not perfect. If the proper module is not loaded by udev on boot, simply modprobe it and add the module name to etc/rc.conf on the '''MODULES=''' line. Note also that udev may occasionally load more than one driver for a device, and the resulting conflict will prevent successful configuration. Be sure to blacklist the unwanted module on the '''MODULES=''' line by prefixing it with a bang (!).<br />
<br />
===Installation===<br />
<br />
====If you have wired internet available====<br />
If you have wired ethernet available, and are simply adding wireless functionality to an existing system, and did not include wireless_tools during initial installation, use pacman to install:<br />
# pacman -S wireless_tools<br />
The drivers' corresponding package names are all highlighted in '''bold''' on this page. The packages can be installed during initial package selection on the Arch installation media and can also be installed later with pacman, e.g.:<br />
# pacman -S madwifi<br />
<br />
====If you have only wireless internet available====<br />
The '''wireless_tools''' package is now available as part of the base system and is also on the live installation media (CD/USB stick image) under the '''base-devel''' category. <br />
<br />
You cannot initialize wireless hardware without these user-space tools, so ensure they are installed from the installer media, (during package selection), especially if you have no means of networking other than wirelessly. Otherwise, you will be stuck in a recursion when you reboot your newly installed Arch system; you will need wireless_tools and drivers, but in order to get them, you will need wireless_tools and drivers.<br />
<br />
===Drivers and firmware===<br />
Methods and procedures for installing drivers for various chip-sets are covered below. In addition, certain chip-sets require the installation of corresponding ''firmware'' (also covered below).<br />
<br />
====wlan-ng (obsolete)====<br />
<br />
Packages: '''wlan-ng26-utils'''<br />
<br />
This driver supports PRISM based cards, which are hard to find now. The PRISM card is an IEEE 802.11 compliant 2.4 GHz DSSS WLAN network interface card that uses the Intersil PRISM chip-set for its radio functions and the AMD PCNet-Mobile chip (AM79C930) for its Media Access Controller (MAC) function. The supported adapters can be found from here: http://www.linux-wlan.org/docs/wlan_adapters.html.gz<br />
<br />
For wlan-ng you do not need the wireless_tools package as mentioned above. Instead you will need to learn the tools in the wlan-ng26-utils package: '''wlancfg and wlanctl-ng'''.<br />
<br />
See http://www.linux-wlan.org/<br />
<br />
====rt2860 and rt2870====<br />
In kernel since 2.6.29 and requires no extra packages. It can be configured using the standard wpa_supplicant and iwconfig tools. Unfortunately this does not go for Arch. In order to get it to work, disabling the following modules has proven to be successful:<br />
<br />
rt2800pci rt61pci rt2x00pci rt2800usb rt2800lib rt2x00usb rt2x00lib<br />
<br />
It has a wide range of options that can be configured with iwpriv. These are documented in the [http://www.ralinktech.com/ralink/Home/Support/Linux.html source tarballs] available from Ralink<br />
<br />
For rt2870sta, also see [[Rt2870]]<br />
<br />
====w322u====<br />
Treat this Tenda card as an rt2870sta. See: [[Rt2870]]<br />
<br />
====rtl8180====<br />
Realtek rtl8180 PCI/Cardbus 802.11b now fully supported in the kernel. It can be configured using the standard wpa_supplicant and iwconfig tools.<br />
<br />
====rtl8192e====<br />
<br />
The driver is part of the current kernel package. It can be configured using the standard wpa_supplicant and iwconfig tools.<br />
<br />
====rtl8192s====<br />
<br />
The driver is part of the current kernel package. Firmware may need to be added manually if /lib/firmware/RTL8192SU/rtl8192sfw.bin does not exist. (dmesg will report ''"rtl819xU:FirmwareRequest92S(): failed"'' if the firmware is missing)<br />
<br />
To download and install firmware:<br />
<pre>$ wget http://launchpadlibrarian.net/33927923/rtl8192se_linux_2.6.0010.1012.2009.tar.gz<br />
# mkdir /lib/firmware/RTL8192SU<br />
# tar -xzOf rtl8192se_linux_2.6.0010.1012.2009.tar.gz \<br />
rtl8192se_linux_2.6.0010.1012.2009/firmware/RTL8192SE/rtl8192sfw.bin > \<br />
/lib/firmware/RTL8192SU/rtl8192sfw.bin</pre><br />
<br />
Note: An alternate version of the firmware may be found [http://launchpadlibrarian.net/37387612/rtl8192sfw.bin.gz here], but this version may cause dropped connections.<br />
<br />
Note: [[wicd]] may cause excessive dropped connections with this driver, while [[NetworkManager]] appears to work better.<br />
<br />
====rt2x00====<br />
Unified driver for Ralink chip-sets (replaces rt2500,rt61,rt73 etc). In kernel since 2.6.24, some devices require extra firmware. It can be configured using the standard wpa_supplicant and iwconfig tools.<br />
<br />
Some chips require a firmware file, which can be installed as follows, depending on the chip-set:<br />
<pre>pacman -S linux-firmware</pre><br />
<br />
See: [[Using the new rt2x00 beta driver]]<br />
<br />
====rt2500, rt61, rt73 (obsolete)====<br />
For Ralink <br />
* PCI/PCMCIA based rt2500 series chip-sets.<br />
* PCI/PCMCIA based rt61 series chip-sets<br />
* USB based rt73 series chip-sets. <br />
<br />
Drivers are now '''obsolete''' and '''unsupported'''. The rt2x00 driver family is stable and to be used instead.<br />
<br />
Support standard iwconfig tools for unencrypted and WEP connections, although it can be quite sensitive to the order of commands.<br />
The driver does support WPA (using hardware encryption), but in a non-standard way. wpa_supplicant appears to include special support for this driver, and it is also possible to negotiate a WPA connection manually using iwpriv commands.<br />
See [http://rt2400.cvs.sourceforge.net/*checkout*/rt2400/source/rt2500/Module/iwpriv_usage.txt these instructions] for details.<br />
<br />
====madwifi-ng====<br />
Package: '''madwifi''' (and optionaly '''madwifi-utils''')<br />
<br />
The module is called <tt>ath_pci</tt>.<br />
<br />
Note there are newer modules maintained by the MadWifi team:<br />
* [[#ath5k|ath5k]] will eventually phase out ath_pci. Currently a better choice for some chipsets.<br />
* [[#ath9k|ath9k]] is the new, official, superior driver for newer Atheros hardware (see below).<br />
<br />
modprobe ath_pci<br />
for the older driver, or:<br />
modprobe ath5k<br />
for the development version. Note that not all cards work with ath5k yet.<br />
<br />
If using ath_pci, you may need to blacklist ath5k by adding it to the MODULES=array in /etc/rc.conf, and subsequently prefixing it with a bang (!):<br />
MODULES=(!ath5k forcedeth snd_intel8x0 ... ...)<br />
<br />
Some users '''may need''' to use the 'countrycode' option when loading the MadWifi driver in order to use channels and transmit power settings that are legal in their country/region. In the Netherlands, for example, you would load the module like this:<br />
<br />
modprobe ath_pci countrycode=528<br />
<br />
You can verify the settings with the <tt>iwlist</tt> command. See <tt>man iwlist</tt> and the [http://madwifi-project.org/wiki/UserDocs/CountryCode CountryCode page on the MadWifi wiki]. To have this setting automatically applied during boot, add the following to <tt>/etc/modprobe.d/modprobe.conf</tt>:<br />
<br />
{{Note| The new module-init-tools 3.8 package changes the location of the configuration file: /etc/modprobe.conf is no longer read, instead /etc/modprobe.d/modprobe.conf is used. [http://www.archlinux.org/news/450/ link]}}<br />
<br />
options ath_pci countrycode=528<br />
<br />
{{Note|A user had to remove the countrycode option completely or else the ath0 device was not created (kernel 2.6.21).}}<br />
<br />
====ath5k====<br />
ath5k is the preferred driver for AR5xxx chipsets including those which are already working with madwifi-ng and for some chipsets older than AR5xxx. <br />
<br />
If ath5k is conflicting with ath_pci on your system, blacklist (and unload using rmmod or reboot) the following drivers...<br />
MODULES=(<br />
...<br />
!ath_hal !ath_pci !ath_rate_amrr !ath_rate_onoe !ath_rate_sample !wlan !wlan_acl !wlan_ccmp !wlan_scan_ap !wlan_scan_sta !wlan_tkip !wlan_wep !wlan_xauth<br />
...<br />
)<br />
<br />
then modprobe ath5k manualy or reboot. wlan0 (or wlanX) in sta mode should spawn and become ready to use.<br />
<br />
Info:<br />
* http://wireless.kernel.org/en/users/Drivers/ath5k<br />
* http://wiki.debian.org/ath5k<br />
<br />
{{Note|Some laptop have problem of Wireless LED indicator flickers red and blue. To solve this problem do :<br />
echo none > "/sys/class/leds/ath5k-phy0::tx/trigger"<br />
echo none > "/sys/class/leds/ath5k-phy0::rx/trigger"<br />
For alternative look {{[https://bugzilla.redhat.com/show_bug.cgi?id=618232 here]}}}}<br />
<br />
====ath9k====<br />
ath9k is Atheros' officially supported driver for the newer 11n chip-sets. All of the chips with 11n capabilities are supported, with a maximum throughput around 180 Mbps. To see a complete list of supported hardware, check this [http://wireless.kernel.org/en/users/Drivers/ath9k page].<br />
<br />
Working modes: Station, AP and Adhoc.<br />
<br />
ath9k has been part of the kernel as of 2.6.27. Support seems acceptable as of 2.6.32 (see [http://linuxwireless.org/en/users/Drivers/ath9k/bugs#Minimal_kernel_requirements details on linuxwireless.org]). (In the unlikely event that you have stability issues that trouble you, you could try using the [http://wireless.kernel.org/en/users/Download compat-wireless] package.<br />
An [https://lists.ath9k.org/mailman/listinfo/ath9k-devel ath9k mailing list] exists for support and development related discussions.)<br />
<br />
Info:<br />
* http://wireless.kernel.org/en/users/Drivers/ath9k<br />
* http://wiki.debian.org/ath9k<br />
<br />
====ath9k_htc====<br />
ath9k_htc is Atheros' officially supported driver for 11n USB devices. Station and Ad-Hoc modes are supported. Since 2.6.35, the driver has been included in the kernel. For more information, see http://wireless.kernel.org/en/users/Drivers/ath9k_htc .<br />
<br />
====ipw2100 and ipw2200====<br />
Fully supported in the kernel, but requires additional firmware. It can be configured using the standard wpa_supplicant and iwconfig tools.<br />
<br />
Depending on which of the chips you have, use either:<br />
<br />
'''ipw2100-fw'''<br />
pacman -S ipw2100-fw<br />
<br />
or:<br />
<br />
'''ipw2200-fw'''<br />
pacman -S ipw2200-fw<br />
<br />
If installing after initial Arch installation, the module may need to be reloaded for the firmware to be loaded; run the following as root:<br />
<br />
rmmod ipw2200<br />
modprobe ipw2200<br />
<br />
=====Enabling the radiotap interface=====<br />
Launch the following (as root):<br />
<br />
rmmod ipw2200<br />
modprobe ipw2200 rtap_iface=1<br />
<br />
=====Enabling the LED=====<br />
Most laptops will have a front LED to indicate when the wireless is connected (or not). Run the following (as root) to enable this feature:<br />
<br />
echo "options ipw2200 led=1" >> /etc/modprobe.d/ipw2200.conf<br />
<br />
or if using sudo:<br />
<br />
echo "options ipw2200 led=1" | sudo tee -a /etc/modprobe.d/ipw2200.conf<br />
<br />
====iwl3945, iwl4965 and iwl5000-series====<br />
'''I'''ntel's open source '''W'''iFi drivers for '''L'''inux (See [http://intellinuxwireless.org iwlwifi]) will work for both the 3945 and 4965 chipsets since kernel v2.6.24. And iwl5000-series chipsets (including 5100BG, 5100ABG, 5100AGN, 5300AGN and 5350AGN) module has been supported since '''kernel 2.6.27''', by the intree driver '''iwlagn'''.<br />
<br />
=====Installing Firmware (Microcode)=====<br />
'''Important:''' Installing these firmware packages is not required since the 2.6.34 kernel<br />
update, when the firmware files were moved to the linux-firmware package:<br />
<br />
# pacman -S linux-firmware<br />
<br />
If you need wireless connectivity to access pacman's repositories, the firmware files are also available direct from Intel. See [http://intellinuxwireless.org/?n=downloads this ] page, select and download the archive.<br />
$ wget http://intellinuxwireless.org/iwlwifi/downloads/iwlwifi-XXXX-ucode-XXX.XX.X.XX.tgz<br />
<br />
After downloading, you must extract and copy the *.ucode file to the firmware directory, commonly /lib/firmware<br />
# tar zxvf iwlwifi-XXXX-ucode-XXX.XX.X.XX.tgz<br />
# cd iwlwifi-XXXX-ucode-XXX.XX.X.XX/<br />
# cp iwlwifi-XXXX-X.ucode /lib/firmware/<br />
<br />
=====Loading the Driver=====<br />
If MOD_AUTOLOAD is set to yes in /etc/rc.conf (it is by default) that should be all that is required. Simply check for the presence of the drivers by running '''ifconfig -a''' from a terminal. There should be a listing for wlan0.<br />
<br />
Do this ONLY if MOD_AUTOLOAD is not set: to manually load the driver at startup, edit <tt>/etc/rc.conf</tt> as root and add '''iwl3945''' or '''iwl4965''' respectively to the MODULES array. For example:<br />
<br />
MODULES=( ... b44 mii '''iwl3945''' snd-mixer-oss ...)<br />
<br />
The drivers should now load after a reboot, and running '''ifconfig -a''' from a terminal should report '''wlan0''' as a new network interface.<br />
<br />
=====Disabling LED blink=====<br />
<br />
The default settings on the module are to have the LED blink on activity. Some people like myself find this extremely annoying. To have the LED on solid when wifi is active:<br />
<br />
# echo "options iwlcore led_mode=1" >> /etc/modprobe.d/modprobe.conf<br />
# rmmod iwlagn<br />
# rmmod iwlcore<br />
# modprobe iwlcore<br />
# modprobe iwlagn<br />
<br />
=====Other Notes=====<br />
* The windows NETw4x32 driver can be used with ndiswrapper as an alternative to the iwl3945 and ipw3945 drivers<br />
* In some cases (specifically a [[Dell Latitude D620]] with Arch 2008.06, though it could happen elsewhere) after installation you may have both iwl3945 and ipw3945 in your <tt>MODULES=()</tt> section of rc.conf. The card will not work with both modules loaded, so you will have to ! out the ipw3945 module and then reboot or remove the module manually before you can use your wireless card.<br />
* By default iwl3945 is configured to only work with networks on channels 1-11. Higher ranges are not allowed in some parts of the world (US). In the EU however channels 12 and 13 are used quite common. To make iwl3945 scan for all channels, add "options cfg80211 ieee80211_regdom=EU" to /etc/modprobe.d/modprobe.conf. With "iwlist f" you can check which channels are allowed.<br />
* If you want to enable more channels on Intel Wifi 5100 (and quite possible other cards too) you can do that with the crda package. After install, edit /etc/conf.d/wireless-regdom and uncomment the line where your country code is found. Add wireless-regdom to your DAEMONS in rc.conf and restart (which is the easiest thing to do). You should now, when writing sudo iwlist wlan0 channel, have access to more channels (depending on your location).<br />
* The wifi power management can be enabled by adding:<br />
iwconfig wlan0(change as appropriate) power on<br />
to /etc/rc.local.<br />
<br />
====ipw3945 (obsolete)====<br />
{{Note| ''The ipw3945 driver is no longer actively developed, and the iwlwifi driver (described above) should work perfectly, but may conflict with the former one. Therefore only one of them should be installed. If you choose to use the iwlwifi driver, the '''ipw3945-ucode''' package is still required.''}}<br />
# pacman -S ipw3945 ipw3945-ucode ipw3945d<br />
To initialize the driver on startup, edit <tt>/etc/rc.conf</tt> as root and add '''ipw3945''' to the MODULES array and '''ipw3945d''' to the DAEMONS array. For example:<br />
<br />
MODULES=(... mii '''ipw3945''' snd-mixer-oss ...)<br />
<br />
DAEMONS=(syslog-ng '''ipw3945d''' network ...)<br />
<br />
'''Note:''' The '''ipw3945d''' daemon ''must'' be inserted BEFORE all other network daemons in the array.<br />
<br />
====orinoco====<br />
This should be part of the kernel package and be installed already.<br />
<br />
Note: Some orinoco chipsets are Hermes I/II. You can use http://aur.archlinux.org/packages.php?ID=9637 to replace the orinoco driver and gain WPA support. See http://ubuntuforums.org/showthread.php?p=2154534#post2154534 for more information.<br />
<br />
To use the driver, blacklist orinoco_cs in rc.conf (!orinoco_cs in the MODULES array) and add wlags49_h1_cs. Example:<br />
MODULES=(!eepro100 ''!orinoco_cs'' '''wlags49_h1_cs''')<br />
<br />
====ndiswrapper====<br />
Ndiswrapper is not a real driver, but you can use it when there are no native Linux kernel drivers for your wireless chips. So it is very useful in some situations. To use it you need the *.inf file from your Windows driver (the *.sys file must also be present in the same directory). Be sure to use drivers appropriate to your architecture (i.e. 32/64bit). If you need to extract these files from an *.exe file, you can use either cabextract or wine. Ndiswrapper is included on the Arch Linux installation CD.<br />
<br />
Follow these steps to configure ndiswrapper.<br />
<pre><br />
#Install the driver to /etc/ndiswrapper/*<br />
ndiswrapper -i filename.inf<br />
#List all installed driver for ndiswrapper<br />
ndiswrapper -l<br />
#Write configuration file in /etc/modprobe.d/ndiswrapper.conf<br />
ndiswrapper -m<br />
depmod -a</pre><br />
<br />
Now the ndiswrapper install is almost finished; you just have to update /etc/rc.conf to load the module at boot (below is a sample of my config; yours might look slightly different):<br />
<br />
<pre>MODULES=(ndiswrapper snd-intel8x0 !usbserial)</pre><br />
<br />
The important part is making sure that ndiswrapper exists on this line, so just add it alongside the other modules. It would be best to test that ndiswrapper will load now, so:<br />
<br />
<pre>modprobe ndiswrapper<br />
iwconfig</pre><br />
<br />
and wlan0 should exist. Check this page if you're having problems:<br />
[http://ndiswrapper.sourceforge.net/joomla/index.php?/component/option,com_openwiki/Itemid,33/id,installation/ Ndiswrapper installation wiki].<br />
<br />
====prism54====<br />
Download the firmware driver for your appropriate card from [http://linuxwireless.org/en/users/Drivers/p54 this site]. Rename the firmware file to 'isl3890'.<br />
If nonexistent, create the directory /lib/firmware and place the file 'isl3890' in it. This should do the trick. [http://bbs.archlinux.org/viewtopic.php?t=16569&start=0&postdays=0&postorder=asc&highlight=siocsifflags+such+file++directory]<br />
<br />
If that did not work, try this:<br />
<br />
*Reload the prism module (modprobe p54usb or modprobe p54pci, depending on your hardware)<br />
alternatively remove your wifi card and then reconnect it<br />
*Use the "dmesg" command, and look at the end of the output it prints out.<br />
Look for a section looking like this: <br />
firmware: requesting '''isl3887usb_bare'''<br />
p54: LM86 firmware<br />
p54: FW rev 2.5.8.0 - Softmac protocol 3.0<br />
and try renaming the firmware file to the name corresponding to the part bolded here.<br />
<br />
If you get message <br />
SIOCSIFFLAGS: Operation not permitted<br />
when performing 'ifconfig wlan0 up' OR <br />
prism54: Your card/socket may be faulty, or IRQ line too busy :(<br />
appears in dmesg this may be because you have both the deprecated kernel module "prism54" and the newer kernel module "p54pci" or "p54usb" loaded at the same time and they are fighting over ownership of the IRQ. Use command "lsmod | grep prism54" to see if indeed the deprecated module is being loaded. If so you need to stop "prism54" loading by blacklisting it (there are several ways to do this which are described elsewhere). Once blacklisted, you may find you have to rename the firmware as prism54 and p54pci/p54usb look for different firmware filenames (i.e. recheck the dmesg output after performing ifconfig wlan0 up).<br />
<br />
====ACX100/111====<br />
packages: tiacx tiacx-firmware<br />
<br />
The driver should tell you which firmware it needs; check /var/log/messages.log or use the dmesg command.<br />
<br />
Link the appropriate firmware to '/lib/firmware':<br />
ln -s /usr/share/tiacx/acx111_2.3.1.31/tiacx111c16 /lib/firmware<br />
<br />
For another way to determine which firmware revision number to use, see the [http://acx100.sourceforge.net/wiki/Firmware "Which firmware" section] of the acx100.sourceforge wiki. For ACX100, you can follow the links provided there, to a table of card model number vs. "firmware files known to work"; you can figure out the rev. number you need, by looking at the suffix there. E.g. a dlink_dwl650+ uses "1.9.8.b", in which case you'd do this:<br />
ln -s /usr/share/tiacx/acx100_1.9.8.b/* /lib/firmware<br />
<br />
If you find that the driver is spamming your kernel log, for example because you're running Kismet with channel-hopping, you could put this in /etc/modprobe.d/modprobe.conf:<br />
options acx debug=0<br />
<br />
{{Note|The open-source acx driver does not support WPA/RSN encryption. Ndiswrapper will have to be used with the windows driver to enable the enhanced encryption. See ndiswrapper, this page, for more details.}}<br />
<br />
==== b43 ====<br />
<br />
This driver is the successor to the bcm43xx driver, and is included in kernel from 2.6.24 on.<br />
<br />
If you haven't discovered you card make yet, run:<br />
<br />
lspci | grep Network<br />
<br />
To see if your Broadcom card is supported and to identify the proper module, look [http://wireless.kernel.org/en/users/Drivers/b43#Known_PCI_devices here]. For known card models in various computers, look [http://linuxwireless.org/en/users/Drivers/b43/devices here]. Define the module to use in {{Filename|/etc/rc.conf}} and blacklist the other module to prevent possible problems or confusion.:<br />
<br />
MODULES=(... !b43legacy b43) # or<br />
MODULES=(... !b43 b43legacy)<br />
<br />
Install the corresponding Broadcom 43xx firmware package for your hardware. The packages are on the [[AUR]]:<br />
<br />
b43-firmware <br />
b43-firmware-legacy # for older cards<br />
<br />
Restart, and configure your device as normal. For more detailed information and installation manuals of b43 driver see [http://wireless.kernel.org/en/users/Drivers/b43 b43 homepage]<br />
<br />
Create a new folder to your home (wifi or any other name)<br />
<br />
sudo pacman -S b43-fwcutter<br />
export FIRMWARE_INSTALL_DIR="/lib/firmware"<br />
wget http://downloads.openwrt.org/sources/broadcom-wl-4.178.10.4.tar.bz2<br />
tar xjf broadcom-wl-4.178.10.4.tar.bz2<br />
cd broadcom-wl-4.178.10.4/linux<br />
sudo b43-fwcutter -w "$FIRMWARE_INSTALL_DIR" wl_apsta.o<br />
<br />
reboot your computer<br />
<br />
Note: those steps were taken from<br />
<br />
[http://wireless.kernel.org/en/users/Drivers/b43/ b43]<br />
<br />
====broadcom-wl====<br />
Some recent Broadcom 43xx cards not supported by bcm43xx or b43. Not just for some 43XX cards. See the [[Broadcom_BCM43XX|Broadcom 43XX wiki page]]. It is available in [http://aur.archlinux.org/packages.php?ID=19514 AUR]. These chipsets are used in most Dell laptops, among others.<br />
<br />
====brcm80211====<br />
[http://wireless.kernel.org/en/users/Drivers/brcm80211 brcm80211] is the new open-source driver for a few modern Broadcom chips. It has been in the kernel since 2.6.37. Here is a current list of supported chips:<br />
{| border="1"<br />
! Name !! PCI-ID<br />
|-<br />
| BCM4313 || 0x4727<br />
|-<br />
| BCM43224 || 0x4353<br />
|-<br />
| BCM43225 || 0x4357<br />
|}<br />
<br />
=====Troubleshooting=====<br />
======Lock-Ups======<br />
There is a common problem with some chips running on multi-core systems where the system will lock up while running 'iwlist scan' (or in the scanning process using a wireless client). The only known solution for this (so far) is to run your system with only one core. This can be done by appending 'maxcpus=1' to your kernel line in GRUB's {{Filename|menu.lst}} (or the equivalent for whatever bootloader you use).<br />
<br />
====rtl8187====<br />
See: [[Rtl8187_wireless|rtl8187]]<br />
<br />
====zd1211rw====<br />
[http://zd1211.wiki.sourceforge.net/ zd1211rw] is a driver for the ZyDAS ZD1211 802.11b/g USB WLAN chipset and it is included in recent versions of the Linux kernel. See [http://www.linuxwireless.org/en/users/Drivers/zd1211rw/devices] for a list of supported devices. You only need to install the firmware for the device: <pre>pacman -S zd1211-firmware</pre><br />
<br />
====carl9170====<br />
[http://wireless.kernel.org/en/users/Drivers/carl9170/ carl9170] is the 802.11n USB driver with GPLv2 firmware for Atheros USB AR9170 devices. It support these [http://wireless.kernel.org/en/users/Drivers/carl9170#available_devices devices]. The firmware is available in [https://aur.archlinux.org/packages.php?ID=44102/ AUR]. The driver is part of '''kernel 2.6.37'''. For older kernel use the driver package from [https://aur.archlinux.org/packages.php?ID=44100/ AUR]. <br />
In addition, to block loading of the older ar9170usb driver module, add !arusb_lnx and !ar9170usb to MODULES() in /etc/rc.conf:<br />
<pre>MODULES=(... !arusb_lnx !ar9170usb ...)</pre><br />
<br />
===Test installation===<br />
After loading your driver run<br />
iwconfig<br />
to ensure a wireless interface (wlan''x'', eth''x'', ath''x'') is created.<br />
<br />
If no such interface is visible, modprobing it might work. To start your driver, use the '''rmmod''' and '''modprobe''' commands (if rmmod fails, continue with modprobe).<br />
<br />
Example: if your driver is called "driverXXX", you would run the following commands:<br />
# rmmod driverXXX<br />
# modprobe driverXXX<br />
<br />
Bring the interface up with <code>ifconfig <interface> up</code>. e.g. assuming the interface is <code>wlan0</code>:<br />
# ifconfig wlan0 up<br />
If you get this error message: <code>SIOCSIFFLAGS: No such file or directory</code> it most certainly means your wireless chipset requires a firmware to function, which you need to install as explained above.<br />
<br />
==Part II: Wireless management==<br />
Assuming that your drivers are installed and working properly, you will need to choose a method for managing your wireless connections. The following subsections will help you decide the best way to do just that.<br />
<br />
Procedure and tools required will depend on several factors:<br />
* The desired nature of configuration management; from a completely manual command line setup procedure repeated at each boot to a software-managed, automated solution<br />
* The encryption type (or lack thereof) which protects the wireless network<br />
* The need for network profiles, if the computer will frequently change networks (such as a laptop)<br />
<br />
===Management methods===<br />
This table shows the different methods that can be used to activate and manage a wireless network connection, depending on the encryption and management types, and the various tools that are required. Although there may be other possibilities, these are the most frequently used:<br />
{| border="1"<br />
! Management || No encryption/WEP || WPA/WPA2 PSK<br />
|-<br />
| Manual, need to repeat at each computer reboot || <code>ifconfig + iwconfig + dhcpcd/ifconfig</code> || <code>ifconfig + iwconfig + wpa_supplicant + dhcpcd/ifconfig</code><br />
|-<br />
| Automatically managed, centralized without network profile support || define interface in <code>/etc/rc.conf</code> || not covered<br />
|-<br />
| Automatically managed, with network profiles support || colspan="2" align="center" | <code>Netcfg, newlan (AUR), wicd, NetworkManager, etc…</code><br />
|}<br />
<br />
More choice guide: <br />
<br />
{| border="1"<br />
! - || Netcfg+Newlan(AUR) || Wicd ||NetworkManager+network-manager-applet<br />
|-<br />
| auto connect at boot || with net-profiles daemon config in rc.conf || yes || yes<br />
|-<br />
| auto connect if dropped <br>or changed location || with net-auto-wireless daemon config in rc.conf || yes || yes<br />
|-<br />
| support 3G Modem || || || yes<br />
|-<br />
| GUI (proposes to manage and connect/disconnect<br> profiles from a systray icon. <br>Automatic wireless detection is also availabl) || with ArchAssitant || yes || yes<br />
|-<br />
| console tools || with wifi-select (AUR) || wicd-curses(part of wicd package) || nmcli<br />
|-<br />
| connect speed || slow || || fast<br />
|}<br />
<br />
Whatever your choice, you should try to connect using the manual method first. This will help you understand the different steps that are required and debug them in case a problem arose. Another tip: if possible (e.g. if you manage your wifi access point), try connecting with no encryption, to check everything works. Then try using encryption, either WEP (simpler to configure -- but crackable in a matter of minutes, so it's hardly more secure than an unencrypted connection) or WPA.<br />
<br />
When it comes to easy of use, NetworkManager (with Gnome network-manager-applet) and wicd have good GUIs and can provide a list of available networks to connect, they prompt for passwords, which is straightforward and highly recommended. (Note Gnome network-manager-applet also works under xfce4 if you install xfce4-xfapplet-plugin first, also there are applet available for KDE.) <br />
<br />
====Manual setup====<br />
The programs provided by the package '''wireless_tools''' are the basic set of tools to set up a wireless network. Moreover, if you use WPA/WPA2 encryption, you will need the package '''wpa_supplicant'''. These powerful userspace console tools work extremely well and allow complete, manual control from the shell.<br />
<br />
These examples assume your wireless device is <code>wlan0</code>. Replace <code>wlan0</code> with the appropriate device name.<br />
{{Note| Depending on your hardware and encryption type, some of these steps may not be necessary. Some cards are known to require interface activation and/or access point scanning before being associated to an access point and being given an IP address. Some experimentation may be required. For instance, WPA/WPA2 users may directly try to activate their wireless network from step 3.}}<br />
<br />
'''Step 0.''' ''(Optional, may be required)'' At this step you may need to set the proper operating mode of the wireless card. More specifically, if you're going to connect an ad-hoc network, you might need to set the operating mode to ''ad-hoc:''<br />
# iwconfig wlan0 mode ad-hoc<br />
<br />
{{Note| Ideally, you should a priori know, which type of network you are going to connect. If you don't, scan the network as described in step 2 below, then, if necessary, return back to this step and change the mode. Also, please, bear in mind that changing the operating mode might require the wlan interface to be ''down'' (<code>ifconfig wlan0 down</code>).}}<br />
<br />
'''Step 1.''' ''(Also optional, may be required)'' Some cards require that the kernel interface be activated before you can use the wireless_tools:<br />
# ifconfig wlan0 up<br />
<br />
'''Step 2.''' See what access points are available:<br />
# iwlist wlan0 scan<br />
<br />
{{Note| If it displays "''Interface does not support scanning''" then you probably forgot to install the firmware. You can also try bringing up the interface first as shown in point 1.}}<br />
<br />
'''Step 3.''' Depending on the encryption, you need to associate your wireless device with the access point to use and pass the encryption key.<br />
<br />
Assuming you want to use the ESSID named <code>MyEssid</code>:<br />
* ''No encryption''<br />
# iwconfig wlan0 essid "MyEssid"<br />
* ''WEP''<br />
using an hexadecimal key:<br />
# iwconfig wlan0 essid "MyEssid" key 1234567890<br />
using an ascii key:<br />
# iwconfig wlan0 essid "MyEssid" key s:asciikey<br />
* ''WPA/WPA2''<br />
<br />
You need to edit the <code>/etc/wpa_supplicant.conf</code> file as described in [[WPA_Supplicant]]. Then, issue this command:<br />
# wpa_supplicant -B -Dwext -i wlan0 -c /etc/wpa_supplicant.conf<br />
<br />
This is assuming your device uses the <code>wext</code> driver. If this does not work, you may need to adjust these options. Check [[WPA_Supplicant]] for more information and troubleshooting.<br />
<br />
Regardless of the method used, you can check if you have associated successfully as follows:<br />
# iwconfig wlan0<br />
<br />
'''Step 4.''' Finally, provide an IP address to the network interface. Simple examples are:<br />
# dhcpcd wlan0<br />
for DHCP, or<br />
# ifconfig wlan0 192.168.0.2<br />
# route add default gw 192.168.0.1<br />
for static IP.<br />
<br />
Note: If you get an timeout error due to a ''waiting for carrier'' problem then you might have to set channel mode to auto for the specific device.<br />
<br />
# iwconfig wlan0 channel auto <br />
<br />
{{Note| Although the manual configuration method will help troubleshoot wireless problems, you will have to retype every command each time you reboot.}}<br />
<br />
====Automatic setup====<br />
There are many solutions to choose from, but remember that all of them are mutually exclusive; you should not run two daemons simultaneously.<br />
<br />
=====Standard network daemon=====<br />
{{Note| This method and configuration examples are only valid for unencrypted or WEP-encrypted networks, which are particularly unsecure. To use WPA/WPA2, you will need to use other solutions such as '''[[netcfg]]''' or '''[[wicd]]'''. Also, avoid mixing these methods as they may create a conflict and prevent the wireless card from functioning.}}<br />
<br />
* The '''/etc/rc.conf''' file is sourced by the network script. Therefore, you may define and configure a simple wireless setup within /etc/rc.conf for a centralized approach with '''wlan_<interface>="<interface> essid <essid>"''' and '''INTERFACES=(<interface1> <interface2>)'''. The name of the network goes in place of '''MyEssid'''.<br />
<br />
For example:<br />
# /etc/rc.conf<br />
eth0="dhcp"<br />
wlan0="dhcp"<br />
wlan_wlan0="wlan0 essid MyEssid" # Unencrypted<br />
#wlan_wlan0="wlan0 essid MyEssid key 1234567890" # hex WEP key<br />
#wlan_wlan0="wlan0 essid MyEssid key s:asciikey" # ascii WEP key<br />
INTERFACES=(eth0 wlan0)<br />
<br />
Not all wireless cards are <code>wlan0</code>. Determine your wireless interface with ifconfig -a. <br />
Atheros-based cards, for example, are typically <code>ath0</code>, so change <code>wlan_wlan0</code> to:<br />
wlan_ath0="ath0 essid MyEssid key 12345678" <br />
Also define ath0 in the INTERFACES=line.)<br />
<br />
* Alternatively, you may define wlan_<interface> within /etc/conf.d/wireless, (which is also sourced by the network script), for a de-centralized approach:<br />
# /etc/conf.d/wireless<br />
wlan_wlan0="wlan0 essid MyEssid"<br />
<br />
These solutions are limited for a laptop which is always on the move. It would be good to have multiple [[Network Profiles]] and be able to easily switch from one to another. That is the aim of network managers, such as netcfg.<br />
<br />
=====Netcfg=====<br />
'''netcfg''' provides a ''versatile, robust and fast'' solution to networking on Arch.<br />
<br />
It uses a profile based setup and is capable of detection and connection to a wide range of network types. This is no harder than using graphical tools. Following the directions above, you can get a list of wireless networks. Then, as with graphical tools, you will need a password.<br />
<br />
See: [[Network Profiles]], and [[Network Profiles development]]<br />
<br />
=====Netcfg Easy Wireless LAN (newlan)=====<br />
newlan is a mono console application that starts a user-friendly wizard to create netcfg profiles, it supports also wired connections.<br />
<br />
Install from [[AUR]]: http://aur.archlinux.org/packages.php?ID=33649<br />
<br />
Or use the [[AUR]] helper of your choice.<br />
<br />
newlan must be run with root privileges:<br />
# sudo newlan -n mynewprofile<br />
<br />
=====Autowifi=====<br />
<br />
{{Box|Autowifi is deprecated|Autowifi has been deprecated in favor of [[netcfg]]'s [[Netcfg#net-auto-wireless|net-auto-wireless]] mode|#DF0000|#FFDFDF}}<br />
<br />
Autowifi is a daemon that configures your wireless network automatically depending on the ESSID. Once configured, no user interaction is necessary and no GUI tools are required.<br />
<br />
See: [[Autowifi]]<br />
<br />
=====Wicd=====<br />
Wicd is a network manager that can handle both wireless and wired connections. It is written in Python and Gtk with fewer dependencies than NetworkManager, making it an ideal solution for lightweight desktop users. Wicd is now available in the extra repository for both i686 and x86_64.<br />
<br />
See: [[Wicd]]<br />
<br />
=====NetworkManager=====<br />
NetworkManager is an advanced network management tool that is enabled by default in most popular GNU/Linux distributions. In addition to managing wired connections, NetworkManager provides worry-free wireless roaming with an easy-to-use GUI program for selecting your desired network. <br />
<br />
See: [[NetworkManager]]<br />
<br />
=====Wifi Radar=====<br />
WiFi Radar is Python/PyGTK2 utility for managing wireless profiles (and ''only'' wireless). It enables you to scan for available networks and create profiles for your preferred networks.<br />
<br />
See: [[Wifi Radar]]<br />
<br />
=====Wlassistant=====<br />
Wlassistant is a very intuitive and straightforward GUI application for managing your wireless connections. <br />
<br />
Install from AUR: http://aur.archlinux.org/packages.php?ID=1726<br />
<br />
Wlassistant must be run with root privileges:<br />
# sudo wlassistant<br />
One method of using wlassistant is to configure your wireless card within /etc/rc.conf, specifying the access point you use most often. On startup, your card will automatically be configured for this ESSID, but if other wireless networks are needed/available, wlassistant can then be invoked to access them. Background the network daemon in /etc/rc.conf, by prefixing it with a @, to avoid boot delays.<br />
<br />
==See also==<br />
*[[Sharing ppp connection with wlan interface]]<br />
<br />
==External links==<br />
*[http://www.gnome.org/projects/NetworkManager/ NetworkManager] -- The official website for NetworkManager<br />
*[http://wicd.sourceforge.net/ WICD] -- The official website for WICD<br />
*[https://lists.anl.gov/mailman/listinfo/wifi-radar Wifi Radar] -- Wifi Radar information page<br />
*[http://madwifi.org/wiki/UserDocs/FirstTimeHowTo The madwifi project's method of installing] -- Recommended if you are having trouble after reading this article</div>PeterLhttps://wiki.archlinux.org/index.php?title=Network_configuration/Wireless&diff=128763Network configuration/Wireless2011-01-23T10:01:48Z<p>PeterL: /* prism54 */</p>
<hr />
<div>[[Category:Communication and network (English)]]<br />
[[Category:Networking (English)]]<br />
[[Category:HOWTOs (English)]]<br />
{{i18n|Wireless_Setup}}<br />
Configuring wireless is a two-part process; the first part is to identify and ensure the correct driver for your wireless device is installed, (they are available on the installation media, so make sure you install them) and to configure the interface. The second is choosing a method of managing wireless connections. This article covers both parts, and provides additional links to wireless management tools.<br />
<br />
'''About new Arch systems:''' The wireless drivers and tools are available during Arch set-up under the ''base-devel'' category. Be sure to install the proper driver for your card. Udev will usually load the appropriate module, thereby creating the wireless interface, in the initial live system of the installer, as well as the newly installed system on your hard drive. If you are configuring your wireless functionality after, and not during, Arch installation, simply ensure the required packages are installed with pacman, (driver, firmware if needed, wireless_tools, wpa_supplicant, etc.) and follow the guidelines below.<br />
<br />
== Part I: Identify Card/Install Driver ==<br />
<br />
=== Identify and Discover if Supported ===<br />
<br />
First you will need to check and see if the Linux kernel has support for your card or if a user-space driver is available for it.<br />
<br />
; Identify your card<br />
<br />
:* You can find your card type by running <br />
lspci | grep -i net<br />
from the command line.<br />
:* Or, if you have a USB device, run<br />
lsusb<br />
<br />
{{Note| The internal wifi card in some laptops can actually be usb device, so make sure you check both commands.}}<br />
<br />
; Discover if card is supported<br />
<br />
:* The [https://help.ubuntu.com/community/WifiDocs/WirelessCardsSupported Ubuntu Wiki] has a good list of wireless cards and whether or not they are supported either in the Linux kernel or by a user-space driver (includes driver name).<br />
:* [http://linux-wless.passys.nl/ Linux Wireless Support] and The Linux Questions' [http://www.linuxquestions.org/hcl/index.php?cat=10 Hardware Compatibility List] (HCL) also have a good database of kernel-friendly hardware. <br />
:* The [http://wireless.kernel.org/en/users/Devices kernel page] additionaly has a matrix of supported hardware.<br />
<br />
; If your card isn't listed<br />
<br />
:* If your wireless hardware isn't listed above, likely it is supported only under Windows (some Broadcom, 3com, etc). For these you will need to use [http://ndiswrapper.sourceforge.net/wiki/index.php/List ndiswrapper]. Ndiswrapper is a wrapper script that allows you to use some Windows drivers in Linux. See the compatibility list [http://ndiswrapper.sourceforge.net/mediawiki/index.php/List here]. You will need the {{Filename|.inf}} and {{Filename|.sys}} files from your Windows install. If you have a newer card, or more exotic card, you might want to look up your exact model name and 'linux' and search the internet before doing this step.<br />
<br />
===How it works===<br />
The default Arch kernel is ''modular'', meaning many of the drivers for machine hardware reside on the hard drive and are available as ''modules''. At boot, udev takes an inventory of your hardware. Udev will load appropriate modules (drivers) for your corresponding hardware, and the driver, in turn, will allow creation of a kernel ''interface''. <br />
<br />
The interface name for different drivers and chipsets will vary. Some examples are wlan0, eth1, and ath0.<br />
<br />
*Note: Udev is not perfect. If the proper module is not loaded by udev on boot, simply modprobe it and add the module name to etc/rc.conf on the '''MODULES=''' line. Note also that udev may occasionally load more than one driver for a device, and the resulting conflict will prevent successful configuration. Be sure to blacklist the unwanted module on the '''MODULES=''' line by prefixing it with a bang (!).<br />
<br />
===Installation===<br />
<br />
====If you have wired internet available====<br />
If you have wired ethernet available, and are simply adding wireless functionality to an existing system, and did not include wireless_tools during initial installation, use pacman to install:<br />
# pacman -S wireless_tools<br />
The drivers' corresponding package names are all highlighted in '''bold''' on this page. The packages can be installed during initial package selection on the Arch installation media and can also be installed later with pacman, e.g.:<br />
# pacman -S madwifi<br />
<br />
====If you have only wireless internet available====<br />
The '''wireless_tools''' package is now available as part of the base system and is also on the live installation media (CD/USB stick image) under the '''base-devel''' category. <br />
<br />
You cannot initialize wireless hardware without these user-space tools, so ensure they are installed from the installer media, (during package selection), especially if you have no means of networking other than wirelessly. Otherwise, you will be stuck in a recursion when you reboot your newly installed Arch system; you will need wireless_tools and drivers, but in order to get them, you will need wireless_tools and drivers.<br />
<br />
===Drivers and firmware===<br />
Methods and procedures for installing drivers for various chip-sets are covered below. In addition, certain chip-sets require the installation of corresponding ''firmware'' (also covered below).<br />
<br />
====wlan-ng (obsolete)====<br />
<br />
Packages: '''wlan-ng26-utils'''<br />
<br />
This driver supports PRISM based cards, which are hard to find now. The PRISM card is an IEEE 802.11 compliant 2.4 GHz DSSS WLAN network interface card that uses the Intersil PRISM chip-set for its radio functions and the AMD PCNet-Mobile chip (AM79C930) for its Media Access Controller (MAC) function. The supported adapters can be found from here: http://www.linux-wlan.org/docs/wlan_adapters.html.gz<br />
<br />
For wlan-ng you do not need the wireless_tools package as mentioned above. Instead you will need to learn the tools in the wlan-ng26-utils package: '''wlancfg and wlanctl-ng'''.<br />
<br />
See http://www.linux-wlan.org/<br />
<br />
====rt2860 and rt2870====<br />
In kernel since 2.6.29 and requires no extra packages. It can be configured using the standard wpa_supplicant and iwconfig tools. Unfortunately this does not go for Arch. In order to get it to work, disabling the following modules has proven to be successful:<br />
<br />
rt2800pci rt61pci rt2x00pci rt2800usb rt2800lib rt2x00usb rt2x00lib<br />
<br />
It has a wide range of options that can be configured with iwpriv. These are documented in the [http://www.ralinktech.com/ralink/Home/Support/Linux.html source tarballs] available from Ralink<br />
<br />
For rt2870sta, also see [[Rt2870]]<br />
<br />
====w322u====<br />
Treat this Tenda card as an rt2870sta. See: [[Rt2870]]<br />
<br />
====rtl8180====<br />
Realtek rtl8180 PCI/Cardbus 802.11b now fully supported in the kernel. It can be configured using the standard wpa_supplicant and iwconfig tools.<br />
<br />
====rtl8192e====<br />
<br />
The driver is part of the current kernel package. It can be configured using the standard wpa_supplicant and iwconfig tools.<br />
<br />
====rtl8192s====<br />
<br />
The driver is part of the current kernel package. Firmware may need to be added manually if /lib/firmware/RTL8192SU/rtl8192sfw.bin does not exist. (dmesg will report ''"rtl819xU:FirmwareRequest92S(): failed"'' if the firmware is missing)<br />
<br />
To download and install firmware:<br />
<pre>$ wget http://launchpadlibrarian.net/33927923/rtl8192se_linux_2.6.0010.1012.2009.tar.gz<br />
# mkdir /lib/firmware/RTL8192SU<br />
# tar -xzOf rtl8192se_linux_2.6.0010.1012.2009.tar.gz \<br />
rtl8192se_linux_2.6.0010.1012.2009/firmware/RTL8192SE/rtl8192sfw.bin > \<br />
/lib/firmware/RTL8192SU/rtl8192sfw.bin</pre><br />
<br />
Note: An alternate version of the firmware may be found [http://launchpadlibrarian.net/37387612/rtl8192sfw.bin.gz here], but this version may cause dropped connections.<br />
<br />
Note: [[wicd]] may cause excessive dropped connections with this driver, while [[NetworkManager]] appears to work better.<br />
<br />
====rt2x00====<br />
Unified driver for Ralink chip-sets (replaces rt2500,rt61,rt73 etc). In kernel since 2.6.24, some devices require extra firmware. It can be configured using the standard wpa_supplicant and iwconfig tools.<br />
<br />
Some chips require a firmware file, which can be installed as follows, depending on the chip-set:<br />
<pre>pacman -S linux-firmware</pre><br />
<br />
See: [[Using the new rt2x00 beta driver]]<br />
<br />
====rt2500, rt61, rt73 (obsolete)====<br />
For Ralink <br />
* PCI/PCMCIA based rt2500 series chip-sets.<br />
* PCI/PCMCIA based rt61 series chip-sets<br />
* USB based rt73 series chip-sets. <br />
<br />
Drivers are now '''obsolete''' and '''unsupported'''. The rt2x00 driver family is stable and to be used instead.<br />
<br />
Support standard iwconfig tools for unencrypted and WEP connections, although it can be quite sensitive to the order of commands.<br />
The driver does support WPA (using hardware encryption), but in a non-standard way. wpa_supplicant appears to include special support for this driver, and it is also possible to negotiate a WPA connection manually using iwpriv commands.<br />
See [http://rt2400.cvs.sourceforge.net/*checkout*/rt2400/source/rt2500/Module/iwpriv_usage.txt these instructions] for details.<br />
<br />
====madwifi-ng====<br />
Package: '''madwifi''' (and optionaly '''madwifi-utils''')<br />
<br />
The module is called <tt>ath_pci</tt>.<br />
<br />
Note there are newer modules maintained by the MadWifi team:<br />
* [[#ath5k|ath5k]] will eventually phase out ath_pci. Currently a better choice for some chipsets.<br />
* [[#ath9k|ath9k]] is the new, official, superior driver for newer Atheros hardware (see below).<br />
<br />
modprobe ath_pci<br />
for the older driver, or:<br />
modprobe ath5k<br />
for the development version. Note that not all cards work with ath5k yet.<br />
<br />
If using ath_pci, you may need to blacklist ath5k by adding it to the MODULES=array in /etc/rc.conf, and subsequently prefixing it with a bang (!):<br />
MODULES=(!ath5k forcedeth snd_intel8x0 ... ...)<br />
<br />
Some users '''may need''' to use the 'countrycode' option when loading the MadWifi driver in order to use channels and transmit power settings that are legal in their country/region. In the Netherlands, for example, you would load the module like this:<br />
<br />
modprobe ath_pci countrycode=528<br />
<br />
You can verify the settings with the <tt>iwlist</tt> command. See <tt>man iwlist</tt> and the [http://madwifi-project.org/wiki/UserDocs/CountryCode CountryCode page on the MadWifi wiki]. To have this setting automatically applied during boot, add the following to <tt>/etc/modprobe.d/modprobe.conf</tt>:<br />
<br />
{{Note| The new module-init-tools 3.8 package changes the location of the configuration file: /etc/modprobe.conf is no longer read, instead /etc/modprobe.d/modprobe.conf is used. [http://www.archlinux.org/news/450/ link]}}<br />
<br />
options ath_pci countrycode=528<br />
<br />
{{Note|A user had to remove the countrycode option completely or else the ath0 device was not created (kernel 2.6.21).}}<br />
<br />
====ath5k====<br />
ath5k is the preferred driver for AR5xxx chipsets including those which are already working with madwifi-ng and for some chipsets older than AR5xxx. <br />
<br />
If ath5k is conflicting with ath_pci on your system, blacklist (and unload using rmmod or reboot) the following drivers...<br />
MODULES=(<br />
...<br />
!ath_hal !ath_pci !ath_rate_amrr !ath_rate_onoe !ath_rate_sample !wlan !wlan_acl !wlan_ccmp !wlan_scan_ap !wlan_scan_sta !wlan_tkip !wlan_wep !wlan_xauth<br />
...<br />
)<br />
<br />
then modprobe ath5k manualy or reboot. wlan0 (or wlanX) in sta mode should spawn and become ready to use.<br />
<br />
Info:<br />
* http://wireless.kernel.org/en/users/Drivers/ath5k<br />
* http://wiki.debian.org/ath5k<br />
<br />
{{Note|Some laptop have problem of Wireless LED indicator flickers red and blue. To solve this problem do :<br />
echo none > "/sys/class/leds/ath5k-phy0::tx/trigger"<br />
echo none > "/sys/class/leds/ath5k-phy0::rx/trigger"<br />
For alternative look {{[https://bugzilla.redhat.com/show_bug.cgi?id=618232 here]}}}}<br />
<br />
====ath9k====<br />
ath9k is Atheros' officially supported driver for the newer 11n chip-sets. All of the chips with 11n capabilities are supported, with a maximum throughput around 180 Mbps. To see a complete list of supported hardware, check this [http://wireless.kernel.org/en/users/Drivers/ath9k page].<br />
<br />
Working modes: Station, AP and Adhoc.<br />
<br />
ath9k has been part of the kernel as of 2.6.27. Support seems acceptable as of 2.6.32 (see [http://linuxwireless.org/en/users/Drivers/ath9k/bugs#Minimal_kernel_requirements details on linuxwireless.org]). (In the unlikely event that you have stability issues that trouble you, you could try using the [http://wireless.kernel.org/en/users/Download compat-wireless] package.<br />
An [https://lists.ath9k.org/mailman/listinfo/ath9k-devel ath9k mailing list] exists for support and development related discussions.)<br />
<br />
Info:<br />
* http://wireless.kernel.org/en/users/Drivers/ath9k<br />
* http://wiki.debian.org/ath9k<br />
<br />
====ath9k_htc====<br />
ath9k_htc is Atheros' officially supported driver for 11n USB devices. Station and Ad-Hoc modes are supported. Since 2.6.35, the driver has been included in the kernel. For more information, see http://wireless.kernel.org/en/users/Drivers/ath9k_htc .<br />
<br />
====ipw2100 and ipw2200====<br />
Fully supported in the kernel, but requires additional firmware. It can be configured using the standard wpa_supplicant and iwconfig tools.<br />
<br />
Depending on which of the chips you have, use either:<br />
<br />
'''ipw2100-fw'''<br />
pacman -S ipw2100-fw<br />
<br />
or:<br />
<br />
'''ipw2200-fw'''<br />
pacman -S ipw2200-fw<br />
<br />
If installing after initial Arch installation, the module may need to be reloaded for the firmware to be loaded; run the following as root:<br />
<br />
rmmod ipw2200<br />
modprobe ipw2200<br />
<br />
=====Enabling the radiotap interface=====<br />
Launch the following (as root):<br />
<br />
rmmod ipw2200<br />
modprobe ipw2200 rtap_iface=1<br />
<br />
=====Enabling the LED=====<br />
Most laptops will have a front LED to indicate when the wireless is connected (or not). Run the following (as root) to enable this feature:<br />
<br />
echo "options ipw2200 led=1" >> /etc/modprobe.d/ipw2200.conf<br />
<br />
or if using sudo:<br />
<br />
echo "options ipw2200 led=1" | sudo tee -a /etc/modprobe.d/ipw2200.conf<br />
<br />
====iwl3945, iwl4965 and iwl5000-series====<br />
'''I'''ntel's open source '''W'''iFi drivers for '''L'''inux (See [http://intellinuxwireless.org iwlwifi]) will work for both the 3945 and 4965 chipsets since kernel v2.6.24. And iwl5000-series chipsets (including 5100BG, 5100ABG, 5100AGN, 5300AGN and 5350AGN) module has been supported since '''kernel 2.6.27''', by the intree driver '''iwlagn'''.<br />
<br />
=====Installing Firmware (Microcode)=====<br />
'''Important:''' Installing these firmware packages is not required since the 2.6.34 kernel<br />
update, when the firmware files were moved to the linux-firmware package:<br />
<br />
# pacman -S linux-firmware<br />
<br />
If you need wireless connectivity to access pacman's repositories, the firmware files are also available direct from Intel. See [http://intellinuxwireless.org/?n=downloads this ] page, select and download the archive.<br />
$ wget http://intellinuxwireless.org/iwlwifi/downloads/iwlwifi-XXXX-ucode-XXX.XX.X.XX.tgz<br />
<br />
After downloading, you must extract and copy the *.ucode file to the firmware directory, commonly /lib/firmware<br />
# tar zxvf iwlwifi-XXXX-ucode-XXX.XX.X.XX.tgz<br />
# cd iwlwifi-XXXX-ucode-XXX.XX.X.XX/<br />
# cp iwlwifi-XXXX-X.ucode /lib/firmware/<br />
<br />
=====Loading the Driver=====<br />
If MOD_AUTOLOAD is set to yes in /etc/rc.conf (it is by default) that should be all that is required. Simply check for the presence of the drivers by running '''ifconfig -a''' from a terminal. There should be a listing for wlan0.<br />
<br />
Do this ONLY if MOD_AUTOLOAD is not set: to manually load the driver at startup, edit <tt>/etc/rc.conf</tt> as root and add '''iwl3945''' or '''iwl4965''' respectively to the MODULES array. For example:<br />
<br />
MODULES=( ... b44 mii '''iwl3945''' snd-mixer-oss ...)<br />
<br />
The drivers should now load after a reboot, and running '''ifconfig -a''' from a terminal should report '''wlan0''' as a new network interface.<br />
<br />
=====Disabling LED blink=====<br />
<br />
The default settings on the module are to have the LED blink on activity. Some people like myself find this extremely annoying. To have the LED on solid when wifi is active:<br />
<br />
# echo "options iwlcore led_mode=1" >> /etc/modprobe.d/modprobe.conf<br />
# rmmod iwlagn<br />
# rmmod iwlcore<br />
# modprobe iwlcore<br />
# modprobe iwlagn<br />
<br />
=====Other Notes=====<br />
* The windows NETw4x32 driver can be used with ndiswrapper as an alternative to the iwl3945 and ipw3945 drivers<br />
* In some cases (specifically a [[Dell Latitude D620]] with Arch 2008.06, though it could happen elsewhere) after installation you may have both iwl3945 and ipw3945 in your <tt>MODULES=()</tt> section of rc.conf. The card will not work with both modules loaded, so you will have to ! out the ipw3945 module and then reboot or remove the module manually before you can use your wireless card.<br />
* By default iwl3945 is configured to only work with networks on channels 1-11. Higher ranges are not allowed in some parts of the world (US). In the EU however channels 12 and 13 are used quite common. To make iwl3945 scan for all channels, add "options cfg80211 ieee80211_regdom=EU" to /etc/modprobe.d/modprobe.conf. With "iwlist f" you can check which channels are allowed.<br />
* If you want to enable more channels on Intel Wifi 5100 (and quite possible other cards too) you can do that with the crda package. After install, edit /etc/conf.d/wireless-regdom and uncomment the line where your country code is found. Add wireless-regdom to your DAEMONS in rc.conf and restart (which is the easiest thing to do). You should now, when writing sudo iwlist wlan0 channel, have access to more channels (depending on your location).<br />
* The wifi power management can be enabled by adding:<br />
iwconfig wlan0(change as appropriate) power on<br />
to /etc/rc.local.<br />
<br />
====ipw3945 (obsolete)====<br />
{{Note| ''The ipw3945 driver is no longer actively developed, and the iwlwifi driver (described above) should work perfectly, but may conflict with the former one. Therefore only one of them should be installed. If you choose to use the iwlwifi driver, the '''ipw3945-ucode''' package is still required.''}}<br />
# pacman -S ipw3945 ipw3945-ucode ipw3945d<br />
To initialize the driver on startup, edit <tt>/etc/rc.conf</tt> as root and add '''ipw3945''' to the MODULES array and '''ipw3945d''' to the DAEMONS array. For example:<br />
<br />
MODULES=(... mii '''ipw3945''' snd-mixer-oss ...)<br />
<br />
DAEMONS=(syslog-ng '''ipw3945d''' network ...)<br />
<br />
'''Note:''' The '''ipw3945d''' daemon ''must'' be inserted BEFORE all other network daemons in the array.<br />
<br />
====orinoco====<br />
This should be part of the kernel package and be installed already.<br />
<br />
Note: Some orinoco chipsets are Hermes I/II. You can use http://aur.archlinux.org/packages.php?ID=9637 to replace the orinoco driver and gain WPA support. See http://ubuntuforums.org/showthread.php?p=2154534#post2154534 for more information.<br />
<br />
To use the driver, blacklist orinoco_cs in rc.conf (!orinoco_cs in the MODULES array) and add wlags49_h1_cs. Example:<br />
MODULES=(!eepro100 ''!orinoco_cs'' '''wlags49_h1_cs''')<br />
<br />
====ndiswrapper====<br />
Ndiswrapper is not a real driver, but you can use it when there are no native Linux kernel drivers for your wireless chips. So it is very useful in some situations. To use it you need the *.inf file from your Windows driver (the *.sys file must also be present in the same directory). Be sure to use drivers appropriate to your architecture (i.e. 32/64bit). If you need to extract these files from an *.exe file, you can use either cabextract or wine. Ndiswrapper is included on the Arch Linux installation CD.<br />
<br />
Follow these steps to configure ndiswrapper.<br />
<pre><br />
#Install the driver to /etc/ndiswrapper/*<br />
ndiswrapper -i filename.inf<br />
#List all installed driver for ndiswrapper<br />
ndiswrapper -l<br />
#Write configuration file in /etc/modprobe.d/ndiswrapper.conf<br />
ndiswrapper -m<br />
depmod -a</pre><br />
<br />
Now the ndiswrapper install is almost finished; you just have to update /etc/rc.conf to load the module at boot (below is a sample of my config; yours might look slightly different):<br />
<br />
<pre>MODULES=(ndiswrapper snd-intel8x0 !usbserial)</pre><br />
<br />
The important part is making sure that ndiswrapper exists on this line, so just add it alongside the other modules. It would be best to test that ndiswrapper will load now, so:<br />
<br />
<pre>modprobe ndiswrapper<br />
iwconfig</pre><br />
<br />
and wlan0 should exist. Check this page if you're having problems:<br />
[http://ndiswrapper.sourceforge.net/joomla/index.php?/component/option,com_openwiki/Itemid,33/id,installation/ Ndiswrapper installation wiki].<br />
<br />
====prism54====<br />
Download the firmware driver for your appropriate card from [http://linuxwireless.org/en/users/Drivers/p54 this site]. Rename the firmware file to 'isl3890'.<br />
If nonexistent, create the directory /lib/firmware and place the file 'isl3890' in it. This should do the trick. [http://bbs.archlinux.org/viewtopic.php?t=16569&start=0&postdays=0&postorder=asc&highlight=siocsifflags+such+file++directory]<br />
<br />
If that did not work, try this:<br />
<br />
*Reload the prism module (modprobe p54usb or modprobe p54pci, depending on your hardware)<br />
alternatively remove your wifi card and then reconnect it<br />
*Use the "dmesg" command, and look at the end of the output it prints out.<br />
Look for a section looking like this: <br />
firmware: requesting '''isl3887usb_bare'''<br />
p54: LM86 firmware<br />
p54: FW rev 2.5.8.0 - Softmac protocol 3.0<br />
and try renaming the firmware file to the name corresponding to the part bolded here.<br />
<br />
If you get message <br />
SIOCSIFFLAGS: Operation not permitted<br />
when performing 'ifconfig wlan0 up' OR <br />
prism54: Your card/socket may be faulty, or IRQ line too busy :(<br />
appears in dmesg this may be because you have both the deprecated kernel module "prism54" and the newer kernel module "p54pci" or "p54usb" loaded at the same time and they are fighting over ownership of the IRQ. Use command "lsmod | grep prism54" to see if indeed the deprecated module is being loaded. If so you need to stop "prism54" loading by blacklisting it (there are several ways to do this which are described elsewhere). Once blacklisted, you may find you have to rename the firmware as prism54 and p54pci/p54usb look for different firmware filenames (see above).<br />
<br />
====ACX100/111====<br />
packages: tiacx tiacx-firmware<br />
<br />
The driver should tell you which firmware it needs; check /var/log/messages.log or use the dmesg command.<br />
<br />
Link the appropriate firmware to '/lib/firmware':<br />
ln -s /usr/share/tiacx/acx111_2.3.1.31/tiacx111c16 /lib/firmware<br />
<br />
For another way to determine which firmware revision number to use, see the [http://acx100.sourceforge.net/wiki/Firmware "Which firmware" section] of the acx100.sourceforge wiki. For ACX100, you can follow the links provided there, to a table of card model number vs. "firmware files known to work"; you can figure out the rev. number you need, by looking at the suffix there. E.g. a dlink_dwl650+ uses "1.9.8.b", in which case you'd do this:<br />
ln -s /usr/share/tiacx/acx100_1.9.8.b/* /lib/firmware<br />
<br />
If you find that the driver is spamming your kernel log, for example because you're running Kismet with channel-hopping, you could put this in /etc/modprobe.d/modprobe.conf:<br />
options acx debug=0<br />
<br />
{{Note|The open-source acx driver does not support WPA/RSN encryption. Ndiswrapper will have to be used with the windows driver to enable the enhanced encryption. See ndiswrapper, this page, for more details.}}<br />
<br />
==== b43 ====<br />
<br />
This driver is the successor to the bcm43xx driver, and is included in kernel from 2.6.24 on.<br />
<br />
If you haven't discovered you card make yet, run:<br />
<br />
lspci | grep Network<br />
<br />
To see if your Broadcom card is supported and to identify the proper module, look [http://wireless.kernel.org/en/users/Drivers/b43#Known_PCI_devices here]. For known card models in various computers, look [http://linuxwireless.org/en/users/Drivers/b43/devices here]. Define the module to use in {{Filename|/etc/rc.conf}} and blacklist the other module to prevent possible problems or confusion.:<br />
<br />
MODULES=(... !b43legacy b43) # or<br />
MODULES=(... !b43 b43legacy)<br />
<br />
Install the corresponding Broadcom 43xx firmware package for your hardware. The packages are on the [[AUR]]:<br />
<br />
b43-firmware <br />
b43-firmware-legacy # for older cards<br />
<br />
Restart, and configure your device as normal. For more detailed information and installation manuals of b43 driver see [http://wireless.kernel.org/en/users/Drivers/b43 b43 homepage]<br />
<br />
Create a new folder to your home (wifi or any other name)<br />
<br />
sudo pacman -S b43-fwcutter<br />
export FIRMWARE_INSTALL_DIR="/lib/firmware"<br />
wget http://downloads.openwrt.org/sources/broadcom-wl-4.178.10.4.tar.bz2<br />
tar xjf broadcom-wl-4.178.10.4.tar.bz2<br />
cd broadcom-wl-4.178.10.4/linux<br />
sudo b43-fwcutter -w "$FIRMWARE_INSTALL_DIR" wl_apsta.o<br />
<br />
reboot your computer<br />
<br />
Note: those steps were taken from<br />
<br />
[http://wireless.kernel.org/en/users/Drivers/b43/ b43]<br />
<br />
====broadcom-wl====<br />
Some recent Broadcom 43xx cards not supported by bcm43xx or b43. Not just for some 43XX cards. See the [[Broadcom_BCM43XX|Broadcom 43XX wiki page]]. It is available in [http://aur.archlinux.org/packages.php?ID=19514 AUR]. These chipsets are used in most Dell laptops, among others.<br />
<br />
====brcm80211====<br />
[http://wireless.kernel.org/en/users/Drivers/brcm80211 brcm80211] is the new open-source driver for a few modern Broadcom chips. It has been in the kernel since 2.6.37. Here is a current list of supported chips:<br />
{| border="1"<br />
! Name !! PCI-ID<br />
|-<br />
| BCM4313 || 0x4727<br />
|-<br />
| BCM43224 || 0x4353<br />
|-<br />
| BCM43225 || 0x4357<br />
|}<br />
<br />
=====Troubleshooting=====<br />
======Lock-Ups======<br />
There is a common problem with some chips running on multi-core systems where the system will lock up while running 'iwlist scan' (or in the scanning process using a wireless client). The only known solution for this (so far) is to run your system with only one core. This can be done by appending 'maxcpus=1' to your kernel line in GRUB's {{Filename|menu.lst}} (or the equivalent for whatever bootloader you use).<br />
<br />
====rtl8187====<br />
See: [[Rtl8187_wireless|rtl8187]]<br />
<br />
====zd1211rw====<br />
[http://zd1211.wiki.sourceforge.net/ zd1211rw] is a driver for the ZyDAS ZD1211 802.11b/g USB WLAN chipset and it is included in recent versions of the Linux kernel. See [http://www.linuxwireless.org/en/users/Drivers/zd1211rw/devices] for a list of supported devices. You only need to install the firmware for the device: <pre>pacman -S zd1211-firmware</pre><br />
<br />
====carl9170====<br />
[http://wireless.kernel.org/en/users/Drivers/carl9170/ carl9170] is the 802.11n USB driver with GPLv2 firmware for Atheros USB AR9170 devices. It support these [http://wireless.kernel.org/en/users/Drivers/carl9170#available_devices devices]. The firmware is available in [https://aur.archlinux.org/packages.php?ID=44102/ AUR]. The driver is part of '''kernel 2.6.37'''. For older kernel use the driver package from [https://aur.archlinux.org/packages.php?ID=44100/ AUR]. <br />
In addition, to block loading of the older ar9170usb driver module, add !arusb_lnx and !ar9170usb to MODULES() in /etc/rc.conf:<br />
<pre>MODULES=(... !arusb_lnx !ar9170usb ...)</pre><br />
<br />
===Test installation===<br />
After loading your driver run<br />
iwconfig<br />
to ensure a wireless interface (wlan''x'', eth''x'', ath''x'') is created.<br />
<br />
If no such interface is visible, modprobing it might work. To start your driver, use the '''rmmod''' and '''modprobe''' commands (if rmmod fails, continue with modprobe).<br />
<br />
Example: if your driver is called "driverXXX", you would run the following commands:<br />
# rmmod driverXXX<br />
# modprobe driverXXX<br />
<br />
Bring the interface up with <code>ifconfig <interface> up</code>. e.g. assuming the interface is <code>wlan0</code>:<br />
# ifconfig wlan0 up<br />
If you get this error message: <code>SIOCSIFFLAGS: No such file or directory</code> it most certainly means your wireless chipset requires a firmware to function, which you need to install as explained above.<br />
<br />
==Part II: Wireless management==<br />
Assuming that your drivers are installed and working properly, you will need to choose a method for managing your wireless connections. The following subsections will help you decide the best way to do just that.<br />
<br />
Procedure and tools required will depend on several factors:<br />
* The desired nature of configuration management; from a completely manual command line setup procedure repeated at each boot to a software-managed, automated solution<br />
* The encryption type (or lack thereof) which protects the wireless network<br />
* The need for network profiles, if the computer will frequently change networks (such as a laptop)<br />
<br />
===Management methods===<br />
This table shows the different methods that can be used to activate and manage a wireless network connection, depending on the encryption and management types, and the various tools that are required. Although there may be other possibilities, these are the most frequently used:<br />
{| border="1"<br />
! Management || No encryption/WEP || WPA/WPA2 PSK<br />
|-<br />
| Manual, need to repeat at each computer reboot || <code>ifconfig + iwconfig + dhcpcd/ifconfig</code> || <code>ifconfig + iwconfig + wpa_supplicant + dhcpcd/ifconfig</code><br />
|-<br />
| Automatically managed, centralized without network profile support || define interface in <code>/etc/rc.conf</code> || not covered<br />
|-<br />
| Automatically managed, with network profiles support || colspan="2" align="center" | <code>Netcfg, newlan (AUR), wicd, NetworkManager, etc…</code><br />
|}<br />
<br />
More choice guide: <br />
<br />
{| border="1"<br />
! - || Netcfg+Newlan(AUR) || Wicd ||NetworkManager+network-manager-applet<br />
|-<br />
| auto connect at boot || with net-profiles daemon config in rc.conf || yes || yes<br />
|-<br />
| auto connect if dropped <br>or changed location || with net-auto-wireless daemon config in rc.conf || yes || yes<br />
|-<br />
| support 3G Modem || || || yes<br />
|-<br />
| GUI (proposes to manage and connect/disconnect<br> profiles from a systray icon. <br>Automatic wireless detection is also availabl) || with ArchAssitant || yes || yes<br />
|-<br />
| console tools || with wifi-select (AUR) || wicd-curses(part of wicd package) || nmcli<br />
|-<br />
| connect speed || slow || || fast<br />
|}<br />
<br />
Whatever your choice, you should try to connect using the manual method first. This will help you understand the different steps that are required and debug them in case a problem arose. Another tip: if possible (e.g. if you manage your wifi access point), try connecting with no encryption, to check everything works. Then try using encryption, either WEP (simpler to configure -- but crackable in a matter of minutes, so it's hardly more secure than an unencrypted connection) or WPA.<br />
<br />
When it comes to easy of use, NetworkManager (with Gnome network-manager-applet) and wicd have good GUIs and can provide a list of available networks to connect, they prompt for passwords, which is straightforward and highly recommended. (Note Gnome network-manager-applet also works under xfce4 if you install xfce4-xfapplet-plugin first, also there are applet available for KDE.) <br />
<br />
====Manual setup====<br />
The programs provided by the package '''wireless_tools''' are the basic set of tools to set up a wireless network. Moreover, if you use WPA/WPA2 encryption, you will need the package '''wpa_supplicant'''. These powerful userspace console tools work extremely well and allow complete, manual control from the shell.<br />
<br />
These examples assume your wireless device is <code>wlan0</code>. Replace <code>wlan0</code> with the appropriate device name.<br />
{{Note| Depending on your hardware and encryption type, some of these steps may not be necessary. Some cards are known to require interface activation and/or access point scanning before being associated to an access point and being given an IP address. Some experimentation may be required. For instance, WPA/WPA2 users may directly try to activate their wireless network from step 3.}}<br />
<br />
'''Step 0.''' ''(Optional, may be required)'' At this step you may need to set the proper operating mode of the wireless card. More specifically, if you're going to connect an ad-hoc network, you might need to set the operating mode to ''ad-hoc:''<br />
# iwconfig wlan0 mode ad-hoc<br />
<br />
{{Note| Ideally, you should a priori know, which type of network you are going to connect. If you don't, scan the network as described in step 2 below, then, if necessary, return back to this step and change the mode. Also, please, bear in mind that changing the operating mode might require the wlan interface to be ''down'' (<code>ifconfig wlan0 down</code>).}}<br />
<br />
'''Step 1.''' ''(Also optional, may be required)'' Some cards require that the kernel interface be activated before you can use the wireless_tools:<br />
# ifconfig wlan0 up<br />
<br />
'''Step 2.''' See what access points are available:<br />
# iwlist wlan0 scan<br />
<br />
{{Note| If it displays "''Interface does not support scanning''" then you probably forgot to install the firmware. You can also try bringing up the interface first as shown in point 1.}}<br />
<br />
'''Step 3.''' Depending on the encryption, you need to associate your wireless device with the access point to use and pass the encryption key.<br />
<br />
Assuming you want to use the ESSID named <code>MyEssid</code>:<br />
* ''No encryption''<br />
# iwconfig wlan0 essid "MyEssid"<br />
* ''WEP''<br />
using an hexadecimal key:<br />
# iwconfig wlan0 essid "MyEssid" key 1234567890<br />
using an ascii key:<br />
# iwconfig wlan0 essid "MyEssid" key s:asciikey<br />
* ''WPA/WPA2''<br />
<br />
You need to edit the <code>/etc/wpa_supplicant.conf</code> file as described in [[WPA_Supplicant]]. Then, issue this command:<br />
# wpa_supplicant -B -Dwext -i wlan0 -c /etc/wpa_supplicant.conf<br />
<br />
This is assuming your device uses the <code>wext</code> driver. If this does not work, you may need to adjust these options. Check [[WPA_Supplicant]] for more information and troubleshooting.<br />
<br />
Regardless of the method used, you can check if you have associated successfully as follows:<br />
# iwconfig wlan0<br />
<br />
'''Step 4.''' Finally, provide an IP address to the network interface. Simple examples are:<br />
# dhcpcd wlan0<br />
for DHCP, or<br />
# ifconfig wlan0 192.168.0.2<br />
# route add default gw 192.168.0.1<br />
for static IP.<br />
<br />
Note: If you get an timeout error due to a ''waiting for carrier'' problem then you might have to set channel mode to auto for the specific device.<br />
<br />
# iwconfig wlan0 channel auto <br />
<br />
{{Note| Although the manual configuration method will help troubleshoot wireless problems, you will have to retype every command each time you reboot.}}<br />
<br />
====Automatic setup====<br />
There are many solutions to choose from, but remember that all of them are mutually exclusive; you should not run two daemons simultaneously.<br />
<br />
=====Standard network daemon=====<br />
{{Note| This method and configuration examples are only valid for unencrypted or WEP-encrypted networks, which are particularly unsecure. To use WPA/WPA2, you will need to use other solutions such as '''[[netcfg]]''' or '''[[wicd]]'''. Also, avoid mixing these methods as they may create a conflict and prevent the wireless card from functioning.}}<br />
<br />
* The '''/etc/rc.conf''' file is sourced by the network script. Therefore, you may define and configure a simple wireless setup within /etc/rc.conf for a centralized approach with '''wlan_<interface>="<interface> essid <essid>"''' and '''INTERFACES=(<interface1> <interface2>)'''. The name of the network goes in place of '''MyEssid'''.<br />
<br />
For example:<br />
# /etc/rc.conf<br />
eth0="dhcp"<br />
wlan0="dhcp"<br />
wlan_wlan0="wlan0 essid MyEssid" # Unencrypted<br />
#wlan_wlan0="wlan0 essid MyEssid key 1234567890" # hex WEP key<br />
#wlan_wlan0="wlan0 essid MyEssid key s:asciikey" # ascii WEP key<br />
INTERFACES=(eth0 wlan0)<br />
<br />
Not all wireless cards are <code>wlan0</code>. Determine your wireless interface with ifconfig -a. <br />
Atheros-based cards, for example, are typically <code>ath0</code>, so change <code>wlan_wlan0</code> to:<br />
wlan_ath0="ath0 essid MyEssid key 12345678" <br />
Also define ath0 in the INTERFACES=line.)<br />
<br />
* Alternatively, you may define wlan_<interface> within /etc/conf.d/wireless, (which is also sourced by the network script), for a de-centralized approach:<br />
# /etc/conf.d/wireless<br />
wlan_wlan0="wlan0 essid MyEssid"<br />
<br />
These solutions are limited for a laptop which is always on the move. It would be good to have multiple [[Network Profiles]] and be able to easily switch from one to another. That is the aim of network managers, such as netcfg.<br />
<br />
=====Netcfg=====<br />
'''netcfg''' provides a ''versatile, robust and fast'' solution to networking on Arch.<br />
<br />
It uses a profile based setup and is capable of detection and connection to a wide range of network types. This is no harder than using graphical tools. Following the directions above, you can get a list of wireless networks. Then, as with graphical tools, you will need a password.<br />
<br />
See: [[Network Profiles]], and [[Network Profiles development]]<br />
<br />
=====Netcfg Easy Wireless LAN (newlan)=====<br />
newlan is a mono console application that starts a user-friendly wizard to create netcfg profiles, it supports also wired connections.<br />
<br />
Install from [[AUR]]: http://aur.archlinux.org/packages.php?ID=33649<br />
<br />
Or use the [[AUR]] helper of your choice.<br />
<br />
newlan must be run with root privileges:<br />
# sudo newlan -n mynewprofile<br />
<br />
=====Autowifi=====<br />
<br />
{{Box|Autowifi is deprecated|Autowifi has been deprecated in favor of [[netcfg]]'s [[Netcfg#net-auto-wireless|net-auto-wireless]] mode|#DF0000|#FFDFDF}}<br />
<br />
Autowifi is a daemon that configures your wireless network automatically depending on the ESSID. Once configured, no user interaction is necessary and no GUI tools are required.<br />
<br />
See: [[Autowifi]]<br />
<br />
=====Wicd=====<br />
Wicd is a network manager that can handle both wireless and wired connections. It is written in Python and Gtk with fewer dependencies than NetworkManager, making it an ideal solution for lightweight desktop users. Wicd is now available in the extra repository for both i686 and x86_64.<br />
<br />
See: [[Wicd]]<br />
<br />
=====NetworkManager=====<br />
NetworkManager is an advanced network management tool that is enabled by default in most popular GNU/Linux distributions. In addition to managing wired connections, NetworkManager provides worry-free wireless roaming with an easy-to-use GUI program for selecting your desired network. <br />
<br />
See: [[NetworkManager]]<br />
<br />
=====Wifi Radar=====<br />
WiFi Radar is Python/PyGTK2 utility for managing wireless profiles (and ''only'' wireless). It enables you to scan for available networks and create profiles for your preferred networks.<br />
<br />
See: [[Wifi Radar]]<br />
<br />
=====Wlassistant=====<br />
Wlassistant is a very intuitive and straightforward GUI application for managing your wireless connections. <br />
<br />
Install from AUR: http://aur.archlinux.org/packages.php?ID=1726<br />
<br />
Wlassistant must be run with root privileges:<br />
# sudo wlassistant<br />
One method of using wlassistant is to configure your wireless card within /etc/rc.conf, specifying the access point you use most often. On startup, your card will automatically be configured for this ESSID, but if other wireless networks are needed/available, wlassistant can then be invoked to access them. Background the network daemon in /etc/rc.conf, by prefixing it with a @, to avoid boot delays.<br />
<br />
==See also==<br />
*[[Sharing ppp connection with wlan interface]]<br />
<br />
==External links==<br />
*[http://www.gnome.org/projects/NetworkManager/ NetworkManager] -- The official website for NetworkManager<br />
*[http://wicd.sourceforge.net/ WICD] -- The official website for WICD<br />
*[https://lists.anl.gov/mailman/listinfo/wifi-radar Wifi Radar] -- Wifi Radar information page<br />
*[http://madwifi.org/wiki/UserDocs/FirstTimeHowTo The madwifi project's method of installing] -- Recommended if you are having trouble after reading this article</div>PeterLhttps://wiki.archlinux.org/index.php?title=Network_configuration/Wireless&diff=128762Network configuration/Wireless2011-01-23T09:52:33Z<p>PeterL: /* prism54 */</p>
<hr />
<div>[[Category:Communication and network (English)]]<br />
[[Category:Networking (English)]]<br />
[[Category:HOWTOs (English)]]<br />
{{i18n|Wireless_Setup}}<br />
Configuring wireless is a two-part process; the first part is to identify and ensure the correct driver for your wireless device is installed, (they are available on the installation media, so make sure you install them) and to configure the interface. The second is choosing a method of managing wireless connections. This article covers both parts, and provides additional links to wireless management tools.<br />
<br />
'''About new Arch systems:''' The wireless drivers and tools are available during Arch set-up under the ''base-devel'' category. Be sure to install the proper driver for your card. Udev will usually load the appropriate module, thereby creating the wireless interface, in the initial live system of the installer, as well as the newly installed system on your hard drive. If you are configuring your wireless functionality after, and not during, Arch installation, simply ensure the required packages are installed with pacman, (driver, firmware if needed, wireless_tools, wpa_supplicant, etc.) and follow the guidelines below.<br />
<br />
== Part I: Identify Card/Install Driver ==<br />
<br />
=== Identify and Discover if Supported ===<br />
<br />
First you will need to check and see if the Linux kernel has support for your card or if a user-space driver is available for it.<br />
<br />
; Identify your card<br />
<br />
:* You can find your card type by running <br />
lspci | grep -i net<br />
from the command line.<br />
:* Or, if you have a USB device, run<br />
lsusb<br />
<br />
{{Note| The internal wifi card in some laptops can actually be usb device, so make sure you check both commands.}}<br />
<br />
; Discover if card is supported<br />
<br />
:* The [https://help.ubuntu.com/community/WifiDocs/WirelessCardsSupported Ubuntu Wiki] has a good list of wireless cards and whether or not they are supported either in the Linux kernel or by a user-space driver (includes driver name).<br />
:* [http://linux-wless.passys.nl/ Linux Wireless Support] and The Linux Questions' [http://www.linuxquestions.org/hcl/index.php?cat=10 Hardware Compatibility List] (HCL) also have a good database of kernel-friendly hardware. <br />
:* The [http://wireless.kernel.org/en/users/Devices kernel page] additionaly has a matrix of supported hardware.<br />
<br />
; If your card isn't listed<br />
<br />
:* If your wireless hardware isn't listed above, likely it is supported only under Windows (some Broadcom, 3com, etc). For these you will need to use [http://ndiswrapper.sourceforge.net/wiki/index.php/List ndiswrapper]. Ndiswrapper is a wrapper script that allows you to use some Windows drivers in Linux. See the compatibility list [http://ndiswrapper.sourceforge.net/mediawiki/index.php/List here]. You will need the {{Filename|.inf}} and {{Filename|.sys}} files from your Windows install. If you have a newer card, or more exotic card, you might want to look up your exact model name and 'linux' and search the internet before doing this step.<br />
<br />
===How it works===<br />
The default Arch kernel is ''modular'', meaning many of the drivers for machine hardware reside on the hard drive and are available as ''modules''. At boot, udev takes an inventory of your hardware. Udev will load appropriate modules (drivers) for your corresponding hardware, and the driver, in turn, will allow creation of a kernel ''interface''. <br />
<br />
The interface name for different drivers and chipsets will vary. Some examples are wlan0, eth1, and ath0.<br />
<br />
*Note: Udev is not perfect. If the proper module is not loaded by udev on boot, simply modprobe it and add the module name to etc/rc.conf on the '''MODULES=''' line. Note also that udev may occasionally load more than one driver for a device, and the resulting conflict will prevent successful configuration. Be sure to blacklist the unwanted module on the '''MODULES=''' line by prefixing it with a bang (!).<br />
<br />
===Installation===<br />
<br />
====If you have wired internet available====<br />
If you have wired ethernet available, and are simply adding wireless functionality to an existing system, and did not include wireless_tools during initial installation, use pacman to install:<br />
# pacman -S wireless_tools<br />
The drivers' corresponding package names are all highlighted in '''bold''' on this page. The packages can be installed during initial package selection on the Arch installation media and can also be installed later with pacman, e.g.:<br />
# pacman -S madwifi<br />
<br />
====If you have only wireless internet available====<br />
The '''wireless_tools''' package is now available as part of the base system and is also on the live installation media (CD/USB stick image) under the '''base-devel''' category. <br />
<br />
You cannot initialize wireless hardware without these user-space tools, so ensure they are installed from the installer media, (during package selection), especially if you have no means of networking other than wirelessly. Otherwise, you will be stuck in a recursion when you reboot your newly installed Arch system; you will need wireless_tools and drivers, but in order to get them, you will need wireless_tools and drivers.<br />
<br />
===Drivers and firmware===<br />
Methods and procedures for installing drivers for various chip-sets are covered below. In addition, certain chip-sets require the installation of corresponding ''firmware'' (also covered below).<br />
<br />
====wlan-ng (obsolete)====<br />
<br />
Packages: '''wlan-ng26-utils'''<br />
<br />
This driver supports PRISM based cards, which are hard to find now. The PRISM card is an IEEE 802.11 compliant 2.4 GHz DSSS WLAN network interface card that uses the Intersil PRISM chip-set for its radio functions and the AMD PCNet-Mobile chip (AM79C930) for its Media Access Controller (MAC) function. The supported adapters can be found from here: http://www.linux-wlan.org/docs/wlan_adapters.html.gz<br />
<br />
For wlan-ng you do not need the wireless_tools package as mentioned above. Instead you will need to learn the tools in the wlan-ng26-utils package: '''wlancfg and wlanctl-ng'''.<br />
<br />
See http://www.linux-wlan.org/<br />
<br />
====rt2860 and rt2870====<br />
In kernel since 2.6.29 and requires no extra packages. It can be configured using the standard wpa_supplicant and iwconfig tools. Unfortunately this does not go for Arch. In order to get it to work, disabling the following modules has proven to be successful:<br />
<br />
rt2800pci rt61pci rt2x00pci rt2800usb rt2800lib rt2x00usb rt2x00lib<br />
<br />
It has a wide range of options that can be configured with iwpriv. These are documented in the [http://www.ralinktech.com/ralink/Home/Support/Linux.html source tarballs] available from Ralink<br />
<br />
For rt2870sta, also see [[Rt2870]]<br />
<br />
====w322u====<br />
Treat this Tenda card as an rt2870sta. See: [[Rt2870]]<br />
<br />
====rtl8180====<br />
Realtek rtl8180 PCI/Cardbus 802.11b now fully supported in the kernel. It can be configured using the standard wpa_supplicant and iwconfig tools.<br />
<br />
====rtl8192e====<br />
<br />
The driver is part of the current kernel package. It can be configured using the standard wpa_supplicant and iwconfig tools.<br />
<br />
====rtl8192s====<br />
<br />
The driver is part of the current kernel package. Firmware may need to be added manually if /lib/firmware/RTL8192SU/rtl8192sfw.bin does not exist. (dmesg will report ''"rtl819xU:FirmwareRequest92S(): failed"'' if the firmware is missing)<br />
<br />
To download and install firmware:<br />
<pre>$ wget http://launchpadlibrarian.net/33927923/rtl8192se_linux_2.6.0010.1012.2009.tar.gz<br />
# mkdir /lib/firmware/RTL8192SU<br />
# tar -xzOf rtl8192se_linux_2.6.0010.1012.2009.tar.gz \<br />
rtl8192se_linux_2.6.0010.1012.2009/firmware/RTL8192SE/rtl8192sfw.bin > \<br />
/lib/firmware/RTL8192SU/rtl8192sfw.bin</pre><br />
<br />
Note: An alternate version of the firmware may be found [http://launchpadlibrarian.net/37387612/rtl8192sfw.bin.gz here], but this version may cause dropped connections.<br />
<br />
Note: [[wicd]] may cause excessive dropped connections with this driver, while [[NetworkManager]] appears to work better.<br />
<br />
====rt2x00====<br />
Unified driver for Ralink chip-sets (replaces rt2500,rt61,rt73 etc). In kernel since 2.6.24, some devices require extra firmware. It can be configured using the standard wpa_supplicant and iwconfig tools.<br />
<br />
Some chips require a firmware file, which can be installed as follows, depending on the chip-set:<br />
<pre>pacman -S linux-firmware</pre><br />
<br />
See: [[Using the new rt2x00 beta driver]]<br />
<br />
====rt2500, rt61, rt73 (obsolete)====<br />
For Ralink <br />
* PCI/PCMCIA based rt2500 series chip-sets.<br />
* PCI/PCMCIA based rt61 series chip-sets<br />
* USB based rt73 series chip-sets. <br />
<br />
Drivers are now '''obsolete''' and '''unsupported'''. The rt2x00 driver family is stable and to be used instead.<br />
<br />
Support standard iwconfig tools for unencrypted and WEP connections, although it can be quite sensitive to the order of commands.<br />
The driver does support WPA (using hardware encryption), but in a non-standard way. wpa_supplicant appears to include special support for this driver, and it is also possible to negotiate a WPA connection manually using iwpriv commands.<br />
See [http://rt2400.cvs.sourceforge.net/*checkout*/rt2400/source/rt2500/Module/iwpriv_usage.txt these instructions] for details.<br />
<br />
====madwifi-ng====<br />
Package: '''madwifi''' (and optionaly '''madwifi-utils''')<br />
<br />
The module is called <tt>ath_pci</tt>.<br />
<br />
Note there are newer modules maintained by the MadWifi team:<br />
* [[#ath5k|ath5k]] will eventually phase out ath_pci. Currently a better choice for some chipsets.<br />
* [[#ath9k|ath9k]] is the new, official, superior driver for newer Atheros hardware (see below).<br />
<br />
modprobe ath_pci<br />
for the older driver, or:<br />
modprobe ath5k<br />
for the development version. Note that not all cards work with ath5k yet.<br />
<br />
If using ath_pci, you may need to blacklist ath5k by adding it to the MODULES=array in /etc/rc.conf, and subsequently prefixing it with a bang (!):<br />
MODULES=(!ath5k forcedeth snd_intel8x0 ... ...)<br />
<br />
Some users '''may need''' to use the 'countrycode' option when loading the MadWifi driver in order to use channels and transmit power settings that are legal in their country/region. In the Netherlands, for example, you would load the module like this:<br />
<br />
modprobe ath_pci countrycode=528<br />
<br />
You can verify the settings with the <tt>iwlist</tt> command. See <tt>man iwlist</tt> and the [http://madwifi-project.org/wiki/UserDocs/CountryCode CountryCode page on the MadWifi wiki]. To have this setting automatically applied during boot, add the following to <tt>/etc/modprobe.d/modprobe.conf</tt>:<br />
<br />
{{Note| The new module-init-tools 3.8 package changes the location of the configuration file: /etc/modprobe.conf is no longer read, instead /etc/modprobe.d/modprobe.conf is used. [http://www.archlinux.org/news/450/ link]}}<br />
<br />
options ath_pci countrycode=528<br />
<br />
{{Note|A user had to remove the countrycode option completely or else the ath0 device was not created (kernel 2.6.21).}}<br />
<br />
====ath5k====<br />
ath5k is the preferred driver for AR5xxx chipsets including those which are already working with madwifi-ng and for some chipsets older than AR5xxx. <br />
<br />
If ath5k is conflicting with ath_pci on your system, blacklist (and unload using rmmod or reboot) the following drivers...<br />
MODULES=(<br />
...<br />
!ath_hal !ath_pci !ath_rate_amrr !ath_rate_onoe !ath_rate_sample !wlan !wlan_acl !wlan_ccmp !wlan_scan_ap !wlan_scan_sta !wlan_tkip !wlan_wep !wlan_xauth<br />
...<br />
)<br />
<br />
then modprobe ath5k manualy or reboot. wlan0 (or wlanX) in sta mode should spawn and become ready to use.<br />
<br />
Info:<br />
* http://wireless.kernel.org/en/users/Drivers/ath5k<br />
* http://wiki.debian.org/ath5k<br />
<br />
{{Note|Some laptop have problem of Wireless LED indicator flickers red and blue. To solve this problem do :<br />
echo none > "/sys/class/leds/ath5k-phy0::tx/trigger"<br />
echo none > "/sys/class/leds/ath5k-phy0::rx/trigger"<br />
For alternative look {{[https://bugzilla.redhat.com/show_bug.cgi?id=618232 here]}}}}<br />
<br />
====ath9k====<br />
ath9k is Atheros' officially supported driver for the newer 11n chip-sets. All of the chips with 11n capabilities are supported, with a maximum throughput around 180 Mbps. To see a complete list of supported hardware, check this [http://wireless.kernel.org/en/users/Drivers/ath9k page].<br />
<br />
Working modes: Station, AP and Adhoc.<br />
<br />
ath9k has been part of the kernel as of 2.6.27. Support seems acceptable as of 2.6.32 (see [http://linuxwireless.org/en/users/Drivers/ath9k/bugs#Minimal_kernel_requirements details on linuxwireless.org]). (In the unlikely event that you have stability issues that trouble you, you could try using the [http://wireless.kernel.org/en/users/Download compat-wireless] package.<br />
An [https://lists.ath9k.org/mailman/listinfo/ath9k-devel ath9k mailing list] exists for support and development related discussions.)<br />
<br />
Info:<br />
* http://wireless.kernel.org/en/users/Drivers/ath9k<br />
* http://wiki.debian.org/ath9k<br />
<br />
====ath9k_htc====<br />
ath9k_htc is Atheros' officially supported driver for 11n USB devices. Station and Ad-Hoc modes are supported. Since 2.6.35, the driver has been included in the kernel. For more information, see http://wireless.kernel.org/en/users/Drivers/ath9k_htc .<br />
<br />
====ipw2100 and ipw2200====<br />
Fully supported in the kernel, but requires additional firmware. It can be configured using the standard wpa_supplicant and iwconfig tools.<br />
<br />
Depending on which of the chips you have, use either:<br />
<br />
'''ipw2100-fw'''<br />
pacman -S ipw2100-fw<br />
<br />
or:<br />
<br />
'''ipw2200-fw'''<br />
pacman -S ipw2200-fw<br />
<br />
If installing after initial Arch installation, the module may need to be reloaded for the firmware to be loaded; run the following as root:<br />
<br />
rmmod ipw2200<br />
modprobe ipw2200<br />
<br />
=====Enabling the radiotap interface=====<br />
Launch the following (as root):<br />
<br />
rmmod ipw2200<br />
modprobe ipw2200 rtap_iface=1<br />
<br />
=====Enabling the LED=====<br />
Most laptops will have a front LED to indicate when the wireless is connected (or not). Run the following (as root) to enable this feature:<br />
<br />
echo "options ipw2200 led=1" >> /etc/modprobe.d/ipw2200.conf<br />
<br />
or if using sudo:<br />
<br />
echo "options ipw2200 led=1" | sudo tee -a /etc/modprobe.d/ipw2200.conf<br />
<br />
====iwl3945, iwl4965 and iwl5000-series====<br />
'''I'''ntel's open source '''W'''iFi drivers for '''L'''inux (See [http://intellinuxwireless.org iwlwifi]) will work for both the 3945 and 4965 chipsets since kernel v2.6.24. And iwl5000-series chipsets (including 5100BG, 5100ABG, 5100AGN, 5300AGN and 5350AGN) module has been supported since '''kernel 2.6.27''', by the intree driver '''iwlagn'''.<br />
<br />
=====Installing Firmware (Microcode)=====<br />
'''Important:''' Installing these firmware packages is not required since the 2.6.34 kernel<br />
update, when the firmware files were moved to the linux-firmware package:<br />
<br />
# pacman -S linux-firmware<br />
<br />
If you need wireless connectivity to access pacman's repositories, the firmware files are also available direct from Intel. See [http://intellinuxwireless.org/?n=downloads this ] page, select and download the archive.<br />
$ wget http://intellinuxwireless.org/iwlwifi/downloads/iwlwifi-XXXX-ucode-XXX.XX.X.XX.tgz<br />
<br />
After downloading, you must extract and copy the *.ucode file to the firmware directory, commonly /lib/firmware<br />
# tar zxvf iwlwifi-XXXX-ucode-XXX.XX.X.XX.tgz<br />
# cd iwlwifi-XXXX-ucode-XXX.XX.X.XX/<br />
# cp iwlwifi-XXXX-X.ucode /lib/firmware/<br />
<br />
=====Loading the Driver=====<br />
If MOD_AUTOLOAD is set to yes in /etc/rc.conf (it is by default) that should be all that is required. Simply check for the presence of the drivers by running '''ifconfig -a''' from a terminal. There should be a listing for wlan0.<br />
<br />
Do this ONLY if MOD_AUTOLOAD is not set: to manually load the driver at startup, edit <tt>/etc/rc.conf</tt> as root and add '''iwl3945''' or '''iwl4965''' respectively to the MODULES array. For example:<br />
<br />
MODULES=( ... b44 mii '''iwl3945''' snd-mixer-oss ...)<br />
<br />
The drivers should now load after a reboot, and running '''ifconfig -a''' from a terminal should report '''wlan0''' as a new network interface.<br />
<br />
=====Disabling LED blink=====<br />
<br />
The default settings on the module are to have the LED blink on activity. Some people like myself find this extremely annoying. To have the LED on solid when wifi is active:<br />
<br />
# echo "options iwlcore led_mode=1" >> /etc/modprobe.d/modprobe.conf<br />
# rmmod iwlagn<br />
# rmmod iwlcore<br />
# modprobe iwlcore<br />
# modprobe iwlagn<br />
<br />
=====Other Notes=====<br />
* The windows NETw4x32 driver can be used with ndiswrapper as an alternative to the iwl3945 and ipw3945 drivers<br />
* In some cases (specifically a [[Dell Latitude D620]] with Arch 2008.06, though it could happen elsewhere) after installation you may have both iwl3945 and ipw3945 in your <tt>MODULES=()</tt> section of rc.conf. The card will not work with both modules loaded, so you will have to ! out the ipw3945 module and then reboot or remove the module manually before you can use your wireless card.<br />
* By default iwl3945 is configured to only work with networks on channels 1-11. Higher ranges are not allowed in some parts of the world (US). In the EU however channels 12 and 13 are used quite common. To make iwl3945 scan for all channels, add "options cfg80211 ieee80211_regdom=EU" to /etc/modprobe.d/modprobe.conf. With "iwlist f" you can check which channels are allowed.<br />
* If you want to enable more channels on Intel Wifi 5100 (and quite possible other cards too) you can do that with the crda package. After install, edit /etc/conf.d/wireless-regdom and uncomment the line where your country code is found. Add wireless-regdom to your DAEMONS in rc.conf and restart (which is the easiest thing to do). You should now, when writing sudo iwlist wlan0 channel, have access to more channels (depending on your location).<br />
* The wifi power management can be enabled by adding:<br />
iwconfig wlan0(change as appropriate) power on<br />
to /etc/rc.local.<br />
<br />
====ipw3945 (obsolete)====<br />
{{Note| ''The ipw3945 driver is no longer actively developed, and the iwlwifi driver (described above) should work perfectly, but may conflict with the former one. Therefore only one of them should be installed. If you choose to use the iwlwifi driver, the '''ipw3945-ucode''' package is still required.''}}<br />
# pacman -S ipw3945 ipw3945-ucode ipw3945d<br />
To initialize the driver on startup, edit <tt>/etc/rc.conf</tt> as root and add '''ipw3945''' to the MODULES array and '''ipw3945d''' to the DAEMONS array. For example:<br />
<br />
MODULES=(... mii '''ipw3945''' snd-mixer-oss ...)<br />
<br />
DAEMONS=(syslog-ng '''ipw3945d''' network ...)<br />
<br />
'''Note:''' The '''ipw3945d''' daemon ''must'' be inserted BEFORE all other network daemons in the array.<br />
<br />
====orinoco====<br />
This should be part of the kernel package and be installed already.<br />
<br />
Note: Some orinoco chipsets are Hermes I/II. You can use http://aur.archlinux.org/packages.php?ID=9637 to replace the orinoco driver and gain WPA support. See http://ubuntuforums.org/showthread.php?p=2154534#post2154534 for more information.<br />
<br />
To use the driver, blacklist orinoco_cs in rc.conf (!orinoco_cs in the MODULES array) and add wlags49_h1_cs. Example:<br />
MODULES=(!eepro100 ''!orinoco_cs'' '''wlags49_h1_cs''')<br />
<br />
====ndiswrapper====<br />
Ndiswrapper is not a real driver, but you can use it when there are no native Linux kernel drivers for your wireless chips. So it is very useful in some situations. To use it you need the *.inf file from your Windows driver (the *.sys file must also be present in the same directory). Be sure to use drivers appropriate to your architecture (i.e. 32/64bit). If you need to extract these files from an *.exe file, you can use either cabextract or wine. Ndiswrapper is included on the Arch Linux installation CD.<br />
<br />
Follow these steps to configure ndiswrapper.<br />
<pre><br />
#Install the driver to /etc/ndiswrapper/*<br />
ndiswrapper -i filename.inf<br />
#List all installed driver for ndiswrapper<br />
ndiswrapper -l<br />
#Write configuration file in /etc/modprobe.d/ndiswrapper.conf<br />
ndiswrapper -m<br />
depmod -a</pre><br />
<br />
Now the ndiswrapper install is almost finished; you just have to update /etc/rc.conf to load the module at boot (below is a sample of my config; yours might look slightly different):<br />
<br />
<pre>MODULES=(ndiswrapper snd-intel8x0 !usbserial)</pre><br />
<br />
The important part is making sure that ndiswrapper exists on this line, so just add it alongside the other modules. It would be best to test that ndiswrapper will load now, so:<br />
<br />
<pre>modprobe ndiswrapper<br />
iwconfig</pre><br />
<br />
and wlan0 should exist. Check this page if you're having problems:<br />
[http://ndiswrapper.sourceforge.net/joomla/index.php?/component/option,com_openwiki/Itemid,33/id,installation/ Ndiswrapper installation wiki].<br />
<br />
====prism54====<br />
Download the firmware driver for your appropriate card from [http://linuxwireless.org/en/users/Drivers/p54 this site]. Rename the firmware file to 'isl3890'.<br />
If nonexistent, create the directory /lib/firmware and place the file 'isl3890' in it. This should do the trick. [http://bbs.archlinux.org/viewtopic.php?t=16569&start=0&postdays=0&postorder=asc&highlight=siocsifflags+such+file++directory]<br />
<br />
If that did not work, try this:<br />
<br />
*Reload the prism module (modprobe p54usb or modprobe p54pci, depending on your hardware)<br />
alternatively remove your wifi card and then reconnect it<br />
*Use the "dmesg" command, and look at the end of the output it prints out.<br />
Look for a section looking like this: <br />
firmware: requesting '''isl3887usb_bare'''<br />
p54: LM86 firmware<br />
p54: FW rev 2.5.8.0 - Softmac protocol 3.0<br />
and try renaming the firmware file to the name corresponding to the part bolded here.<br />
<br />
If you get message <br />
SIOCSIFFLAGS: Operation not permitted<br />
when performing 'ifconfig wlan0 up' OR <br />
prism54: Your card/socket may be faulty, or IRQ line too busy :(<br />
appears in dmesg this may be because you have both the deprecated kernel module "prism54" and the newer kernel module "p54pci" or "p54usb" loaded at the same time and they are fighting over ownership of the IRQ. Use command "lsmod | grep prism54" to see if indeed the deprecated module is being loaded. If so you need to stop the "prism54" loading.<br />
<br />
====ACX100/111====<br />
packages: tiacx tiacx-firmware<br />
<br />
The driver should tell you which firmware it needs; check /var/log/messages.log or use the dmesg command.<br />
<br />
Link the appropriate firmware to '/lib/firmware':<br />
ln -s /usr/share/tiacx/acx111_2.3.1.31/tiacx111c16 /lib/firmware<br />
<br />
For another way to determine which firmware revision number to use, see the [http://acx100.sourceforge.net/wiki/Firmware "Which firmware" section] of the acx100.sourceforge wiki. For ACX100, you can follow the links provided there, to a table of card model number vs. "firmware files known to work"; you can figure out the rev. number you need, by looking at the suffix there. E.g. a dlink_dwl650+ uses "1.9.8.b", in which case you'd do this:<br />
ln -s /usr/share/tiacx/acx100_1.9.8.b/* /lib/firmware<br />
<br />
If you find that the driver is spamming your kernel log, for example because you're running Kismet with channel-hopping, you could put this in /etc/modprobe.d/modprobe.conf:<br />
options acx debug=0<br />
<br />
{{Note|The open-source acx driver does not support WPA/RSN encryption. Ndiswrapper will have to be used with the windows driver to enable the enhanced encryption. See ndiswrapper, this page, for more details.}}<br />
<br />
==== b43 ====<br />
<br />
This driver is the successor to the bcm43xx driver, and is included in kernel from 2.6.24 on.<br />
<br />
If you haven't discovered you card make yet, run:<br />
<br />
lspci | grep Network<br />
<br />
To see if your Broadcom card is supported and to identify the proper module, look [http://wireless.kernel.org/en/users/Drivers/b43#Known_PCI_devices here]. For known card models in various computers, look [http://linuxwireless.org/en/users/Drivers/b43/devices here]. Define the module to use in {{Filename|/etc/rc.conf}} and blacklist the other module to prevent possible problems or confusion.:<br />
<br />
MODULES=(... !b43legacy b43) # or<br />
MODULES=(... !b43 b43legacy)<br />
<br />
Install the corresponding Broadcom 43xx firmware package for your hardware. The packages are on the [[AUR]]:<br />
<br />
b43-firmware <br />
b43-firmware-legacy # for older cards<br />
<br />
Restart, and configure your device as normal. For more detailed information and installation manuals of b43 driver see [http://wireless.kernel.org/en/users/Drivers/b43 b43 homepage]<br />
<br />
Create a new folder to your home (wifi or any other name)<br />
<br />
sudo pacman -S b43-fwcutter<br />
export FIRMWARE_INSTALL_DIR="/lib/firmware"<br />
wget http://downloads.openwrt.org/sources/broadcom-wl-4.178.10.4.tar.bz2<br />
tar xjf broadcom-wl-4.178.10.4.tar.bz2<br />
cd broadcom-wl-4.178.10.4/linux<br />
sudo b43-fwcutter -w "$FIRMWARE_INSTALL_DIR" wl_apsta.o<br />
<br />
reboot your computer<br />
<br />
Note: those steps were taken from<br />
<br />
[http://wireless.kernel.org/en/users/Drivers/b43/ b43]<br />
<br />
====broadcom-wl====<br />
Some recent Broadcom 43xx cards not supported by bcm43xx or b43. Not just for some 43XX cards. See the [[Broadcom_BCM43XX|Broadcom 43XX wiki page]]. It is available in [http://aur.archlinux.org/packages.php?ID=19514 AUR]. These chipsets are used in most Dell laptops, among others.<br />
<br />
====brcm80211====<br />
[http://wireless.kernel.org/en/users/Drivers/brcm80211 brcm80211] is the new open-source driver for a few modern Broadcom chips. It has been in the kernel since 2.6.37. Here is a current list of supported chips:<br />
{| border="1"<br />
! Name !! PCI-ID<br />
|-<br />
| BCM4313 || 0x4727<br />
|-<br />
| BCM43224 || 0x4353<br />
|-<br />
| BCM43225 || 0x4357<br />
|}<br />
<br />
=====Troubleshooting=====<br />
======Lock-Ups======<br />
There is a common problem with some chips running on multi-core systems where the system will lock up while running 'iwlist scan' (or in the scanning process using a wireless client). The only known solution for this (so far) is to run your system with only one core. This can be done by appending 'maxcpus=1' to your kernel line in GRUB's {{Filename|menu.lst}} (or the equivalent for whatever bootloader you use).<br />
<br />
====rtl8187====<br />
See: [[Rtl8187_wireless|rtl8187]]<br />
<br />
====zd1211rw====<br />
[http://zd1211.wiki.sourceforge.net/ zd1211rw] is a driver for the ZyDAS ZD1211 802.11b/g USB WLAN chipset and it is included in recent versions of the Linux kernel. See [http://www.linuxwireless.org/en/users/Drivers/zd1211rw/devices] for a list of supported devices. You only need to install the firmware for the device: <pre>pacman -S zd1211-firmware</pre><br />
<br />
====carl9170====<br />
[http://wireless.kernel.org/en/users/Drivers/carl9170/ carl9170] is the 802.11n USB driver with GPLv2 firmware for Atheros USB AR9170 devices. It support these [http://wireless.kernel.org/en/users/Drivers/carl9170#available_devices devices]. The firmware is available in [https://aur.archlinux.org/packages.php?ID=44102/ AUR]. The driver is part of '''kernel 2.6.37'''. For older kernel use the driver package from [https://aur.archlinux.org/packages.php?ID=44100/ AUR]. <br />
In addition, to block loading of the older ar9170usb driver module, add !arusb_lnx and !ar9170usb to MODULES() in /etc/rc.conf:<br />
<pre>MODULES=(... !arusb_lnx !ar9170usb ...)</pre><br />
<br />
===Test installation===<br />
After loading your driver run<br />
iwconfig<br />
to ensure a wireless interface (wlan''x'', eth''x'', ath''x'') is created.<br />
<br />
If no such interface is visible, modprobing it might work. To start your driver, use the '''rmmod''' and '''modprobe''' commands (if rmmod fails, continue with modprobe).<br />
<br />
Example: if your driver is called "driverXXX", you would run the following commands:<br />
# rmmod driverXXX<br />
# modprobe driverXXX<br />
<br />
Bring the interface up with <code>ifconfig <interface> up</code>. e.g. assuming the interface is <code>wlan0</code>:<br />
# ifconfig wlan0 up<br />
If you get this error message: <code>SIOCSIFFLAGS: No such file or directory</code> it most certainly means your wireless chipset requires a firmware to function, which you need to install as explained above.<br />
<br />
==Part II: Wireless management==<br />
Assuming that your drivers are installed and working properly, you will need to choose a method for managing your wireless connections. The following subsections will help you decide the best way to do just that.<br />
<br />
Procedure and tools required will depend on several factors:<br />
* The desired nature of configuration management; from a completely manual command line setup procedure repeated at each boot to a software-managed, automated solution<br />
* The encryption type (or lack thereof) which protects the wireless network<br />
* The need for network profiles, if the computer will frequently change networks (such as a laptop)<br />
<br />
===Management methods===<br />
This table shows the different methods that can be used to activate and manage a wireless network connection, depending on the encryption and management types, and the various tools that are required. Although there may be other possibilities, these are the most frequently used:<br />
{| border="1"<br />
! Management || No encryption/WEP || WPA/WPA2 PSK<br />
|-<br />
| Manual, need to repeat at each computer reboot || <code>ifconfig + iwconfig + dhcpcd/ifconfig</code> || <code>ifconfig + iwconfig + wpa_supplicant + dhcpcd/ifconfig</code><br />
|-<br />
| Automatically managed, centralized without network profile support || define interface in <code>/etc/rc.conf</code> || not covered<br />
|-<br />
| Automatically managed, with network profiles support || colspan="2" align="center" | <code>Netcfg, newlan (AUR), wicd, NetworkManager, etc…</code><br />
|}<br />
<br />
More choice guide: <br />
<br />
{| border="1"<br />
! - || Netcfg+Newlan(AUR) || Wicd ||NetworkManager+network-manager-applet<br />
|-<br />
| auto connect at boot || with net-profiles daemon config in rc.conf || yes || yes<br />
|-<br />
| auto connect if dropped <br>or changed location || with net-auto-wireless daemon config in rc.conf || yes || yes<br />
|-<br />
| support 3G Modem || || || yes<br />
|-<br />
| GUI (proposes to manage and connect/disconnect<br> profiles from a systray icon. <br>Automatic wireless detection is also availabl) || with ArchAssitant || yes || yes<br />
|-<br />
| console tools || with wifi-select (AUR) || wicd-curses(part of wicd package) || nmcli<br />
|-<br />
| connect speed || slow || || fast<br />
|}<br />
<br />
Whatever your choice, you should try to connect using the manual method first. This will help you understand the different steps that are required and debug them in case a problem arose. Another tip: if possible (e.g. if you manage your wifi access point), try connecting with no encryption, to check everything works. Then try using encryption, either WEP (simpler to configure -- but crackable in a matter of minutes, so it's hardly more secure than an unencrypted connection) or WPA.<br />
<br />
When it comes to easy of use, NetworkManager (with Gnome network-manager-applet) and wicd have good GUIs and can provide a list of available networks to connect, they prompt for passwords, which is straightforward and highly recommended. (Note Gnome network-manager-applet also works under xfce4 if you install xfce4-xfapplet-plugin first, also there are applet available for KDE.) <br />
<br />
====Manual setup====<br />
The programs provided by the package '''wireless_tools''' are the basic set of tools to set up a wireless network. Moreover, if you use WPA/WPA2 encryption, you will need the package '''wpa_supplicant'''. These powerful userspace console tools work extremely well and allow complete, manual control from the shell.<br />
<br />
These examples assume your wireless device is <code>wlan0</code>. Replace <code>wlan0</code> with the appropriate device name.<br />
{{Note| Depending on your hardware and encryption type, some of these steps may not be necessary. Some cards are known to require interface activation and/or access point scanning before being associated to an access point and being given an IP address. Some experimentation may be required. For instance, WPA/WPA2 users may directly try to activate their wireless network from step 3.}}<br />
<br />
'''Step 0.''' ''(Optional, may be required)'' At this step you may need to set the proper operating mode of the wireless card. More specifically, if you're going to connect an ad-hoc network, you might need to set the operating mode to ''ad-hoc:''<br />
# iwconfig wlan0 mode ad-hoc<br />
<br />
{{Note| Ideally, you should a priori know, which type of network you are going to connect. If you don't, scan the network as described in step 2 below, then, if necessary, return back to this step and change the mode. Also, please, bear in mind that changing the operating mode might require the wlan interface to be ''down'' (<code>ifconfig wlan0 down</code>).}}<br />
<br />
'''Step 1.''' ''(Also optional, may be required)'' Some cards require that the kernel interface be activated before you can use the wireless_tools:<br />
# ifconfig wlan0 up<br />
<br />
'''Step 2.''' See what access points are available:<br />
# iwlist wlan0 scan<br />
<br />
{{Note| If it displays "''Interface does not support scanning''" then you probably forgot to install the firmware. You can also try bringing up the interface first as shown in point 1.}}<br />
<br />
'''Step 3.''' Depending on the encryption, you need to associate your wireless device with the access point to use and pass the encryption key.<br />
<br />
Assuming you want to use the ESSID named <code>MyEssid</code>:<br />
* ''No encryption''<br />
# iwconfig wlan0 essid "MyEssid"<br />
* ''WEP''<br />
using an hexadecimal key:<br />
# iwconfig wlan0 essid "MyEssid" key 1234567890<br />
using an ascii key:<br />
# iwconfig wlan0 essid "MyEssid" key s:asciikey<br />
* ''WPA/WPA2''<br />
<br />
You need to edit the <code>/etc/wpa_supplicant.conf</code> file as described in [[WPA_Supplicant]]. Then, issue this command:<br />
# wpa_supplicant -B -Dwext -i wlan0 -c /etc/wpa_supplicant.conf<br />
<br />
This is assuming your device uses the <code>wext</code> driver. If this does not work, you may need to adjust these options. Check [[WPA_Supplicant]] for more information and troubleshooting.<br />
<br />
Regardless of the method used, you can check if you have associated successfully as follows:<br />
# iwconfig wlan0<br />
<br />
'''Step 4.''' Finally, provide an IP address to the network interface. Simple examples are:<br />
# dhcpcd wlan0<br />
for DHCP, or<br />
# ifconfig wlan0 192.168.0.2<br />
# route add default gw 192.168.0.1<br />
for static IP.<br />
<br />
Note: If you get an timeout error due to a ''waiting for carrier'' problem then you might have to set channel mode to auto for the specific device.<br />
<br />
# iwconfig wlan0 channel auto <br />
<br />
{{Note| Although the manual configuration method will help troubleshoot wireless problems, you will have to retype every command each time you reboot.}}<br />
<br />
====Automatic setup====<br />
There are many solutions to choose from, but remember that all of them are mutually exclusive; you should not run two daemons simultaneously.<br />
<br />
=====Standard network daemon=====<br />
{{Note| This method and configuration examples are only valid for unencrypted or WEP-encrypted networks, which are particularly unsecure. To use WPA/WPA2, you will need to use other solutions such as '''[[netcfg]]''' or '''[[wicd]]'''. Also, avoid mixing these methods as they may create a conflict and prevent the wireless card from functioning.}}<br />
<br />
* The '''/etc/rc.conf''' file is sourced by the network script. Therefore, you may define and configure a simple wireless setup within /etc/rc.conf for a centralized approach with '''wlan_<interface>="<interface> essid <essid>"''' and '''INTERFACES=(<interface1> <interface2>)'''. The name of the network goes in place of '''MyEssid'''.<br />
<br />
For example:<br />
# /etc/rc.conf<br />
eth0="dhcp"<br />
wlan0="dhcp"<br />
wlan_wlan0="wlan0 essid MyEssid" # Unencrypted<br />
#wlan_wlan0="wlan0 essid MyEssid key 1234567890" # hex WEP key<br />
#wlan_wlan0="wlan0 essid MyEssid key s:asciikey" # ascii WEP key<br />
INTERFACES=(eth0 wlan0)<br />
<br />
Not all wireless cards are <code>wlan0</code>. Determine your wireless interface with ifconfig -a. <br />
Atheros-based cards, for example, are typically <code>ath0</code>, so change <code>wlan_wlan0</code> to:<br />
wlan_ath0="ath0 essid MyEssid key 12345678" <br />
Also define ath0 in the INTERFACES=line.)<br />
<br />
* Alternatively, you may define wlan_<interface> within /etc/conf.d/wireless, (which is also sourced by the network script), for a de-centralized approach:<br />
# /etc/conf.d/wireless<br />
wlan_wlan0="wlan0 essid MyEssid"<br />
<br />
These solutions are limited for a laptop which is always on the move. It would be good to have multiple [[Network Profiles]] and be able to easily switch from one to another. That is the aim of network managers, such as netcfg.<br />
<br />
=====Netcfg=====<br />
'''netcfg''' provides a ''versatile, robust and fast'' solution to networking on Arch.<br />
<br />
It uses a profile based setup and is capable of detection and connection to a wide range of network types. This is no harder than using graphical tools. Following the directions above, you can get a list of wireless networks. Then, as with graphical tools, you will need a password.<br />
<br />
See: [[Network Profiles]], and [[Network Profiles development]]<br />
<br />
=====Netcfg Easy Wireless LAN (newlan)=====<br />
newlan is a mono console application that starts a user-friendly wizard to create netcfg profiles, it supports also wired connections.<br />
<br />
Install from [[AUR]]: http://aur.archlinux.org/packages.php?ID=33649<br />
<br />
Or use the [[AUR]] helper of your choice.<br />
<br />
newlan must be run with root privileges:<br />
# sudo newlan -n mynewprofile<br />
<br />
=====Autowifi=====<br />
<br />
{{Box|Autowifi is deprecated|Autowifi has been deprecated in favor of [[netcfg]]'s [[Netcfg#net-auto-wireless|net-auto-wireless]] mode|#DF0000|#FFDFDF}}<br />
<br />
Autowifi is a daemon that configures your wireless network automatically depending on the ESSID. Once configured, no user interaction is necessary and no GUI tools are required.<br />
<br />
See: [[Autowifi]]<br />
<br />
=====Wicd=====<br />
Wicd is a network manager that can handle both wireless and wired connections. It is written in Python and Gtk with fewer dependencies than NetworkManager, making it an ideal solution for lightweight desktop users. Wicd is now available in the extra repository for both i686 and x86_64.<br />
<br />
See: [[Wicd]]<br />
<br />
=====NetworkManager=====<br />
NetworkManager is an advanced network management tool that is enabled by default in most popular GNU/Linux distributions. In addition to managing wired connections, NetworkManager provides worry-free wireless roaming with an easy-to-use GUI program for selecting your desired network. <br />
<br />
See: [[NetworkManager]]<br />
<br />
=====Wifi Radar=====<br />
WiFi Radar is Python/PyGTK2 utility for managing wireless profiles (and ''only'' wireless). It enables you to scan for available networks and create profiles for your preferred networks.<br />
<br />
See: [[Wifi Radar]]<br />
<br />
=====Wlassistant=====<br />
Wlassistant is a very intuitive and straightforward GUI application for managing your wireless connections. <br />
<br />
Install from AUR: http://aur.archlinux.org/packages.php?ID=1726<br />
<br />
Wlassistant must be run with root privileges:<br />
# sudo wlassistant<br />
One method of using wlassistant is to configure your wireless card within /etc/rc.conf, specifying the access point you use most often. On startup, your card will automatically be configured for this ESSID, but if other wireless networks are needed/available, wlassistant can then be invoked to access them. Background the network daemon in /etc/rc.conf, by prefixing it with a @, to avoid boot delays.<br />
<br />
==See also==<br />
*[[Sharing ppp connection with wlan interface]]<br />
<br />
==External links==<br />
*[http://www.gnome.org/projects/NetworkManager/ NetworkManager] -- The official website for NetworkManager<br />
*[http://wicd.sourceforge.net/ WICD] -- The official website for WICD<br />
*[https://lists.anl.gov/mailman/listinfo/wifi-radar Wifi Radar] -- Wifi Radar information page<br />
*[http://madwifi.org/wiki/UserDocs/FirstTimeHowTo The madwifi project's method of installing] -- Recommended if you are having trouble after reading this article</div>PeterL