闰秒终于要取消了!一文详解其来源及影响

22c26590822b03ebf9bcc11441432b5a.jpeg

导读 | 第27届国际计量大会宣布最迟不晚于2035年取消引入闰秒,这一消息引起轰动。上一次闰秒产生,对Reddit、Mozilla、FourSquare等都产生了一定的问题,其中Reddit宕机时间超过1个半小时!本栏目特邀腾讯后台开发工程师陶松桥,带你是深入了解闰秒的来源及其影响,并介绍各类系统常见的闰秒处理方法,其中会分享TencentOS Server 操作系统的解决方案。

1eebe537f944f00abcf63529f286bec5.jpeg

闰秒从何而来

世界上有几种计量时间的方式:

世界时(UT1):是一种天文计量的方式,天文学家通过观测地球的自转,并将自转一周的时间(一天)等分为864000份,每份为一秒,受潮汐等因素的影响,地球自转一周的时间并不是恒定的,这也是造成闰秒现象的直接原因。

原子时(TAI):由于上面描述的世界时并不稳定,物理学家用更为稳定的量子计量的方式来统计时间,1967年,国际计量大会用铯133(Cs133)原子基态的两个超精细能级之间的跃迁所对应辐射的9192631770个周期所持续的时间定义为1秒,这个是目前最精确的时间计量方式,其误差为1400000年一秒,基本可忽略不计。

协调世界时(UTC):又称世界标准时间或世界协调时间,UTC以TAI为基础,又要兼顾UT1,当UTC,和UT1之间的偏差接近1秒时,国际地球自转和参考系服务(IERS)会提前6个月公布下一次闰秒的时间。

我们将世界绝大多数地方时区的基本时间称为协调世界时,即 UTC。它源自分布在世界一些国家的大量原子时钟。地球的自转并不是非常恒定的,有时会有一些变化,平均自转速度会缓慢下降。这就是为什么会在 UTC 时标中插入所谓闰秒,它们可将 UTC 时间进程调整到真实地球自转时间。

为什么会多出这一秒呢?它的存在是因为决定昼夜更替的地球绕轴自转会在很长的一段时间内慢下来,主要是由月亮-太阳引力造成。另外,地球也受其内部(地核、地幔)和外部(气候、海洋)构成影响。目前,时间主要由分属几个国家的 250 台原子时钟测量,这些原子钟是通过测量原子的能量转换水平工作。使用这些时钟计算 UTC,同时因为这个时间测量原理周期性地与地球不同步,因此必须使用闰秒进行校正。另外,我们必须考虑到现在的一天比 1820 年的一天要长 2 毫秒。不出所料,地球自转慢慢就与 UTC 不同步了。

国际地球自转服务局IERS 测量的是真实地球自转,并决定何时插入闰秒。插入闰秒一般总是在某个月的最后一天进行,首选六月或十二月的 UTC 午夜时间。过去每次添加闰秒都是在六月或十二月进行。是否添加闰秒的声明,会由 IERS 在其Bulletin C 中发布。目前,在可能添加闰秒日期前半年会公布 Bulletin C 。

因为闰秒是在全世界同时插入,插入闰秒的本地(民用)时间取决于本地时间与 UTC 之间的偏差,例如:2015年7月1日发生闰秒时,在时区 UTC+8h(北京时间) 中,闰秒会在时钟显示午夜后 8 小时的时候插入。

闰秒时计算北京时间的标准方法为:

 
2015-07-01 07.59.57
2015-07-01 07.59.58
2015-07-01 07.59.59
2015-07-01 07.59.60 <-- 闰秒
2015-07-01 08.00.00
2015-07-01 08.00.01
2015-07-01 08.00.02

如果系统时钟采用国际原子时(TAI),并使用正确的时区,那么就会列出 23:59:60。但因为在 Unix 的 UTC 使用中不存在 23:59:60,Linux内核会采用倒回一秒的方法在 0:00 UTC 后第一次时钟更新时插入闰秒。在本地时间计时中,根据不同的时区偏差,比如 UTC+8h,在TencentOS Server系统中,您会观察到以下现象:

 
2015-07-01  07:59:58.000
2015-07-01  07:59:58.500
2015-07-01  07:59:59.000
2015-07-01  07:59:59.500
2015-07-01  08:00:00.000 <-- 插入闰秒
2015-07-01  07:59:59.000
2015-07-01  07:59:59.500
2015-07-01  08:00:00.000
2015-07-01  08:00:00.500

IERS 确定闰秒后,一些时间传播服务还会发布闰秒通知。这包括德国长波发射机 DCF77 和卫星巡航系统 GPS 示例。因此,可解码从那些系统获取信号的接收器也可以解码闰秒通知。如果在所应用协议中包含闰秒信息(例如接收器传送的时间字符串),则从那些接收器读取时间的应用程序也可以确定闰秒通知。请注意,时间代码接收器只能将闰秒通知转发到应用程序,同时正确计时。正确处理闰秒是应用程序和(/或)操作系统的任务。

从1972年到2020年,平均每21个月就插入一次闰秒。然而,间隔是非常不规则的,而且明显在增加。在1999年1月1日至2004年12月31日的六年中没有闰秒,但在1972-1979年的八年中有九个闰秒。自1972年协调世界时正式使用至今,全球已经实施了27次正闰秒调整,最近一次的闰秒调整是格林尼治时间2016年12月31日。从协调世界时正式使用以来,地球自转一直处于不断减慢的趋势,因此迄今为止的闰秒都是正闰秒。但相关科研发现,自2020年年中以来,地球自转速率呈现加快趋势,这意味着未来也可能会出现负闰秒目前TAI与UTC的秒差为37:

#  Value of TAI-UTC in second valid beetween the initial value until
#  the epoch given on the next line. The last line reads that NO
#  leap second was introduced since the corresponding date 
#  Updated through IERS Bulletin 64 issued in July 2022
#  
#
#  File expires on 28 June 2023
#
#
#    MJD        Date        TAI-UTC (s)
#           day month year
#    ---    --------------   ------   
#41317.0    1  1 1972       1041499.0    1  7 1972       1141683.0    1  1 1973       1242048.0    1  1 1974       1342413.0    1  1 1975       1442778.0    1  1 1976       1543144.0    1  1 1977       1643509.0    1  1 1978       1743874.0    1  1 1979       1844239.0    1  1 1980       1944786.0    1  7 1981       2045151.0    1  7 1982       2145516.0    1  7 1983       2246247.0    1  7 1985       2347161.0    1  1 1988       2447892.0    1  1 1990       2548257.0    1  1 1991       2648804.0    1  7 1992       2749169.0    1  7 1993       2849534.0    1  7 1994       2950083.0    1  1 1996       3050630.0    1  7 1997       3151179.0    1  1 1999       3253736.0    1  1 2006       3354832.0    1  1 2009       3456109.0    1  7 2012       3557204.0    1  7 2015       3657754.0    1  1 2017       37

43e8a262ebee8f2c9006041ce347edf3.jpeg闰秒处理方案

1)运行NTP的系统

系统如果使用 NTP(网络时间协议)守护进程(ntpd)将其本地计时与 NTP 服务器同步,则都应自动进行闰秒调整。进行闰秒调整的前一天,NTP 服务器应通知其客户端第二天的 23:59:59 UTC 会发生发生闰秒,Linux 内核应通过两次显示第 60 秒或彻底删除它,以便添加或者删除额外一秒。因此,在闰秒调整期间,运行 NTP 的系统应有如下计时显示:

2015-06-30 23:59:59 UTC
2015-06-30 23:59:59 UTC
2015-06-30 00:00:00 UTC

发生闰秒时,内核会在系统 log 中写入信息:

Jul  1 07:59:59 TENCENT64 kernel: [579201.951291] Clock: inserting leap second 23:59:60 UTC

使用ntpdate命令方式,与ntp服务器进行时间同步的系统,将不会通过ntp服务器接收到闰秒通知,而是在系统管理员指定的时刻与ntp服务器进行时间同步。例如,系统管理员设定每小时的第52分与ntp服务器进行时间同步,那么在7月1日08:00 CST到09:52之间,系统时间与ntp服务器时间会相差1秒(快1秒)。

2)运行PTP的系统

PTP(精确时间协议)中交换的时间戳通常采用不包含闰秒的TAI(国际原子时);但 ptp4l 和 phc2sys 将设置内核标签,插入闰秒以便系统时钟继续以 UTC 运行。然后该内核就可以正常插入闰秒。

3)未运行NTP或者PTP的系统

默认情况下,不使用 NTP 或者 PTP 同步其计时的 Linux 系统不会修正闰秒,且这些系统报告的时间与修正闰秒后的 UTC 时间有一秒钟的差别。闰秒发生后应手动重置时钟。

您还可以将 tzdata 更新至最新版本,将 /usr/share/zoneinfo/right 目录层级中的正确文件复制到 /etc/localtime,并将时钟重置到正确的本地时间,以便将这些系统配置可正确报告时间。  /usr/share/zoneinfo/right 中的文件包含自该世纪开始,从 1970 年 1 月 1 日 00:00:00 UTC 发生的所有闰秒修正的本地时间信息。  /usr/share/zoneinfo 中的其他时区文件未添加闰秒修正。 从1972年至今,共添加了 27次闰秒。

例如:如果某个系统位于中国时区,您可以将其重新配置为通过运行以下命令报告闰秒修正时间,

 
cp /usr/share/zoneinfo/right/Asia/Shanghai /etc/localtime

例如在TS2系统中,tzdata包的版本为tzdata-2015a-1.tl2.noarch,执行完上述拷贝后,则会在闰秒发生时间2015年7月1日8点自动插入闰秒。

4)windows系统

早期的Windows版本(Win10版本以前) 时间服务并不表示 Leap 指标的值,当 Windows 时间服务接收到的数据包,包括闰秒。因此,闰秒发生后,正在运行 Windows 时间服务的 NTP 客户端会比实际时间快一秒。这种时间差异在下次同步时解决。

从 Windows 10 Redstone 5 和 Windows Server 2019 起,微软的操作系统能以更精确、UTC 兼容和可追踪的方式处理闰秒。不过从2017年至今,没有发生过闰秒了。

aaac6e6a8fdcd8a4baa34998381ec443.jpeg历史影响

对于日常生活而言,正常的上班、下班、工作、学习,生命中偏差的这一秒无关痛痒。然而闰秒对于精确要求时间的行业如航空、航天、军工等,会产生较大影响。对于服务器清一色linux系统的互联网行业而言,闰秒可能会造成机器cpu突然增高,机器宕机、对应的服务挂掉。随着linux的普遍使用,闰秒的影响也被越来越多的被关注。

历史上,因为linux内核的一些问题,闰秒对系统造成多次影响。比如CPU利用率高会给生产环境带了不少挑战。2012年实施闰秒时,国外不少知名网站出现了临时服务中断。当2015年闰秒再度来临时,工程师们修复了部分2012年出现的问题,但却东窗事发——发现了新的问题。后续亦是如此。闰秒让互联网企业如鲠在喉。

1) linux-2.6.22以前内核版本的闰秒死锁

07年的commit:

http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=746976a301ac9c9aa10d7d42454f8d6cdad8ff2b;hp=872aad45d6174570dd2e1defc3efee50f2cfcc72

每次时钟中断触发时会调用 tick_do_update_jiffies64 更新 jiffies 的 值。因此在更新前对 xtime_lock 加了写锁。闰秒产生时,开发者需要修正 jiffies 的值。在 tick_do_update_jiffies64 里面最终会调用到 second_overflow 这个函数,以处理润秒。在函数 second_overflow 里面,处理润秒的增加和减少前都调用了一个 clock_was_set 函数。该函数内部,请求了 xtime_lock 的读锁。此时,与先前的写锁发生死锁。

该patch在linux内核版本2.6.22中引入,所以只有2.6.22内核之前的系统可会出现该问题,也就是影响sles10和centos5.5系统。在sles10和centos5.5中,clock_was_set()因不支持高精度时钟而被定义为空,所以不造成影响。

2)linux-2.6.25到2.6.27内核版本的系统死锁

Bug 479765 - Leap second message can hang the kernel 描述了leap second会对系统产生影响的原因:

当一个leap second被插入或删除时,内核会打印一条相关信息:

[69596.647516] Clock: inserting leap second 23:59:60 UTC

而该信息的打印会因xtime_lock而造成系统死锁。

下面是2.6.26内核下该问题出现时的栈信息(this is with Fedora 8 and

kernel kernel-2.6.26.6-49.fc8.x86_64):

#0  ktime_get_ts (ts=0xffffffff8158bb30) at include/asm/processor.h:691
#1  0xffffffff8104c09a in ktime_get () at kernel/hrtimer.c:59
#2  0xffffffff8102a39a in hrtick_start_fair (rq=0xffff810009013880, p=<value optimized out>) at kernel/sched.c:1064
#3  0xffffffff8102decc in enqueue_task_fair (rq=0xffff810009013880, p=0xffff81003fb02d40, wakeup=1) at kernel/sched_fair.c:863
#4  0xffffffff81029a08 in enqueue_task (rq=0xffffffff8158bb30, p=0xffff81003b8ac418, wakeup=-994836480) at kernel/sched.c:1550
#5  0xffffffff81029a39 in activate_task (rq=0xffff810009013880, p=0xffff81003b8ac418, wakeup=20045) at kernel/sched.c:1614
#6  0xffffffff8102be38 in try_to_wake_up (p=0xffff81003fb02d40, state=<value optimized out>, sync=0) at kernel/sched.c:2173
#7  0xffffffff8102be9c in default_wake_function (curr=<value optimized out>, mode=998949912, sync=20045, key=0x4c4b40000) at kernel/sched.c:4366
#8  0xffffffff810492ed in autoremove_wake_function (wait=0xffffffff8158bb30, mode=998949912, sync=20045, key=0x4c4b40000) at kernel/wait.c:132
#9  0xffffffff810296a2 in __wake_up_common (q=0xffffffff813d3180, mode=1, nr_exclusive=1, sync=0, key=0x0) at kernel/sched.c:4387
#10 0xffffffff8102b97b in __wake_up (q=0xffffffff813d3180, mode=1, nr_exclusive=1, key=0x0) at kernel/sched.c:4406
#11 0xffffffff8103692f in wake_up_klogd () at kernel/printk.c:1005
#12 0xffffffff81036abb in release_console_sem () at kernel/printk.c:1051
#13 0xffffffff81036fd1 in vprintk (fmt=<value optimized out>, args=<value optimized out>) at kernel/printk.c:789
#14 0xffffffff81037081 in printk (fmt=0xffffffff8158bb30 "yj$\201????\2008\001\t") at kernel/printk.c:613
#15 0xffffffff8104ec16 in ntp_leap_second (timer=<value optimized out>)at kernel/time/ntp.c:143
#16 0xffffffff8104b7a6 in run_hrtimer_pending (cpu_base=0xffff81000900f740)at kernel/hrtimer.c:1204
#17 0xffffffff8104b86a in run_hrtimer_softirq (h=<value optimized out>)at kernel/hrtimer.c:1355
#18 0xffffffff8103b31f in __do_softirq () at kernel/softirq.c:234
#19 0xffffffff8100d52c in call_softirq () at include/asm/current_64.h:10
#20 0xffffffff8100ed5e in do_softirq () at arch/x86/kernel/irq_64.c:262
#21 0xffffffff8103b280 in irq_exit () at kernel/softirq.c:310
#22 0xffffffff8101b0fe in smp_apic_timer_interrupt (regs=<value optimized out>)at arch/x86/kernel/apic_64.c:514
#23 0xffffffff8100cf52 in apic_timer_interrupt ()at include/asm/current_64.h:10
#24 0xffff81003b9d5a90 in ?? ()
#25 0x0000000000000000 in ?? ()

从上面的栈信息我们可以发现:该问题的出现原因是当对leap second进行操作(插入或删除)之前,已经获取了xtime_lock锁;而之后在调用printk()打印日志信息时,printk()中会尝试唤醒klogd内核线程,在唤醒过程中会调用到公平调度类的相关函数,其中会调用ktime_get()获取时间信息,其中会再次尝试获取xtime_lock锁,从而造成死锁

该现象部分因为hrtick_start_fair()函数的引入。是由commit 8f4d37ec (high-res preemption tick)引发,这大概在2.6.25版本引入。但是在2.6.25之前的内核,不会发生这个死锁。

2.6.28版本引入了commit b845b517。printk()中的wake_up_klogd()不会直接wake_up klogd(),也就不会触发后续的xtime_lock,最终避免了死锁的发生。所以,该原因引起的系统死锁只可能发生在linux内核2.6.25到2.6.27版本下

Sles11使用2.6.27内核,属于比较危险的部分内核。但是Novell声称已经引入了commit b845b517b5e3706a3729f6ea83b88ab85f0725b0,因而不存在该问题,而且几个小时的实验后系统仍然正常。

此问题影响的版本还有 RHEL4:kernel-2.6.9.89.EL之前的版本,RHEL5.3:kernel-2.6.18-128.37.1.el5之前的版本。现网centos5.5使用的内核版本是2.6.18-194.el5,其不受影响。

3)linux-3.4内核版本的系统活锁

08年的commit中为了解决之前遇到的leap second问题而将对leap second的处理从second_overflow()中独立出来,使用定时器来完成此工作。

但是12年的commit认为该patch存在如下可能的livelock场景:

CPU 0                                                                         CPU 1
do_adjtimex()
spin_lock_irq(&ntp_lock);
process_adjtimex_modes();                                   timer_interrupt()
process_adj_status();                                        do_timer()
ntp_start_leap_timer();                                     write_lock(&xtime_lock);
hrtimer_start();                                             update_wall_time();
hrtimer_reprogram();                                     ntp_tick_length()
tick_program_event()                                     spin_lock(&ntp_lock);
clockevents_program_event()
ktime_get()
seq = req_seqbegin(xtime_lock);

问题在于,引入ntp_lock的commit(http://patches.linaro.org/5122/)

是在3.4内核版本,且在3.4内核得到了修复。所以此问题对3.4以前和以后的内核无影响。

08年的commit:https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=7dffa3c673fbcf835cd7be80bb4aec8ad3f51168

12年的commit:

https://lkml.org/lkml/2012/3/15/616

4)linux-2.6.32内核插入闰秒可能出现高CPU消耗

2012年的闰秒插入当时导致了一些互联网公司的服务器高cpu消耗,其问题根源在以下网址得到了阐述:https://lkml.org/lkml/2012/7/1/203

leap-a-day.c为一个小测试程序,编译后加-s参数运行,可每10秒插入或者删除一个闰秒,用户可自行下载编译测试。2015年7月1日的闰秒将会出现以下现象:

Setting time to Wed Jul  1 07:59:50 2015
Scheduling leap second for Wed Jul  1 08:00:00 2015
Wed Jul  1 07:59:57 2015 +     98 us (3883)     TIME_INS
Wed Jul  1 07:59:57 2015 + 500248 us (3883)     TIME_INS
Wed Jul  1 07:59:58 2015 +    366 us (3883)     TIME_INS
Wed Jul  1 07:59:58 2015 + 500483 us (3883)     TIME_INS
Wed Jul  1 07:59:59 2015 +    598 us (3883)     TIME_INS
Wed Jul  1 07:59:59 2015 + 500740 us (3883)     TIME_INS
Wed Jul  1 07:59:59 2015 +    910 us (3883)     TIME_OOP
Wed Jul  1 07:59:59 2015 + 501046 us (3883)     TIME_OOP
Wed Jul  1 08:00:00 2015 +   1214 us (3884)     TIME_WAIT
Wed Jul  1 08:00:00 2015 + 501359 us (3884)     TIME_WAIT
Wed Jul  1 08:00:01 2015 +   1481 us (3884)     TIME_WAIT
Wed Jul  1 08:00:01 2015 + 501599 us (3884)     TIME_WAIT
Wed Jul  1 08:00:02 2015 +   1650 us (3884)     TIME_WAIT

我们测试后发现,在TS1.2发行版下,可出现“ERROR: hrtimer early expiration failure observed”提示。

/* Test for known hrtimer failure */
void test_hrtimer_failure(void)
{struct timespec now, target;clock_gettime(CLOCK_REALTIME, &now);target = timespec_add(now, NSEC_PER_SEC/2);clock_nanosleep(CLOCK_REALTIME, TIMER_ABSTIME, &target, NULL);clock_gettime(CLOCK_REALTIME, &now);if (!in_order(target, now)){printf("ERROR: hrtimer early expiration failure observed.\n");}

分析代码可以发现:使用clock_nanosleep(CLOCK_REALTIME, TIMER_ABSTIME, &target, NULL);这种定时器方式,在插入闰秒后,该定时器本应该0.5秒到期,却立刻到期。本质原因是内核中记录时间的数据结构中并没有表达闰秒的地方,因此在增加闰秒时需要特别调整这些数据结构。而很多定时器并不直接使用“绝对”时钟而使用相对的时间间隔,这样,在定时器代码中就应该对闰秒做额外的检查。

但问题是这样的检查之前被删掉。对于许多应用来说,定时器的一次提前触发并不是什么问题。但有些定时器则不然,他们会反复启动自己,这样的后果就是它们反复地被快速唤醒,于是系统负载就出现了观察到的尖峰现象。闰秒的插入没有调用clock_was_set(),来提醒hrtimer子系统改变。定时器在插入闰秒后,其基准比系统时间快一秒,因此会提前一秒到期。

在观察到cpu高消耗后,解决方法很简单,执行下述命令即可:

date -s "`date`"

其原理就是date再设置一下当前系统时间,clock_settime(CLOCK_REALTIME,&ts)会调用clock_was_set()。为了应对ntpd同步可能出现的该问题,我们在2015年特意编写了一个解决程序,该程序经过编译后可以添加到crontab任务:

58 7 1 7 * /data/solve_hrtimer_failure.o > /data/solve_hrtimer_failure.log 2>&1

在7月1日7点58分开始,每隔100ms检测闰秒是否插入了,当插入闰秒后,该程序调用clock_settime函数,进而修复了该问题。

b0174646d3ff6d2eace51ddb9c02c177.jpeg取消闰秒

1)为何取消闰秒

对闰秒最为敏感的莫过于计算机相关领域。由于闰秒的出现没有固定规律,对应的时间调整无法从一开始就写在计算机程序里。在万物互联时代,很多领域都依托计算机网络传输信息,实施闰秒也会影响航空、通信、金融及其他需要精准对时的领域。

今年7月Meta公司两名工程师发文称:“闰秒是一种弊大于利的冒险做法,我们认为现在是时候引入新技术来取代它了。”这一表态引来各大公司称道。

2)取消闰秒的后续可能

负责协调世界时的国际计量局(BIPM)表示,科学家和政府代表18日在法国举行的一次会议上投票决定到2035年取消闰秒。BIPM时间部门负责人帕特里齐亚·塔维拉表示,这项“历史性决定”将允许“秒数连续流动,而不会出现目前由不规则闰秒造成的不连续性。

闰秒是目前把世界时和国际原子时联系起来的手段。由于世界时是基于地球自转确定的,又称天文时或太阳时。没有闰秒意味着人们使用的时间与地球自转、太阳位置不关联,时间和天文学呈现割裂状态。

第27届国际计量大会决议要求多机构协商,提出一个可以将协调世界时持续至少百年的新方案并制定实施计划,纳入下一届大会的决议草案中。根据决议,闰秒将暂时继续正常添加。但到2035年,世界时和国际原子时之间的差异将被允许增长到大于一秒的值。

也许解决这个问题的可能方法是让世界时和国际原子时之间的差异增加到一分钟,但专家估计调整时长在50到100年之间。而有提议指出,无需在时钟上增加闰分钟,而是将某一天的最后一分钟变为需要两分钟;也有人建议停止校正,同时公布世界时和国际原子时之间不断增长的时刻差。

腾讯工程师技术干货直达:

1、算法工程师深度解构ChatGPT技术

2、10分钟!从架构视角读懂K8s

3、探秘微信业务优化:DDD从入门到实践

4、祖传代码重构:从25万行到5万行的血泪史

4775cea355722ea925e07a8b010260e0.png

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处:http://www.rhkb.cn/news/22857.html

如若内容造成侵权/违法违规/事实不符,请联系长河编程网进行投诉反馈email:809451989@qq.com,一经查实,立即删除!

相关文章

GPT-5暂时来不了 OpenAI悄然布局移动端

OpenAI彻底用GPT-4带火自然语言大模型后&#xff0c;互联网科技行业的大头、小头都在推出自家的大模型或产品。一时间&#xff0c;生成式AI竞速赛上演&#xff0c;“吃瓜群众”也等着看谁能跑赢OpenAI。 坊间预测&#xff0c;干掉GPT-4的还得是GPT-5。结果&#xff0c;OpenAI的…

悄然招募移动端工程师 OpenAI矛头调向移动端

2022年底&#xff0c;人工智能程序ChatGPT爆火&#xff0c;上线短短两月&#xff0c;就获1亿月度活跃用户&#xff0c;成为历史上增长最快的面向消费者的应用。随后全球的科技巨头都热火朝天地入局自然语言大模型赛道。不过推出ChatGPT的人工智能巨头OpenAI目前并不打算训练GPT…

马斯克宣布打造 ChatGPT 竞品!OpenAI CEO 给他泼了一盆冷水,GPT-5 或将大变

无脑增加 模型规模 已经落伍 当你在 ChatGPT 或者新 bing 里输入一个问题&#xff0c;AI 会调用它的云端大脑&#xff0c;思索一番&#xff0c;生成一段较为合理的回答。 而在 OpenAI 开发 GPT 时&#xff0c;也反复提到了参数正变得庞大&#xff0c;模型的规模也在逐代变得复…

死磕数据库系列(二十六):MySQL 高可用之单主、双主模型组复制配置实践

点关注公众号&#xff0c;回复“1024”获取2TB学习资源&#xff01; 前面我们学习&#xff1a;MySQL 高可用之组复制&#xff08;MGR&#xff09;技术的相关原理知识&#xff0c;今天我将详细的为大家介绍 MySQL 高可用技术组复制的单主、双主两种模型下的原理及配置相关知识&a…

chatgpt赋能python:Python中三角函数的使用

Python中三角函数的使用 介绍 Python是一种非常流行的编程语言&#xff0c;因为它非常易于学习和使用。Python中有很多实用的库和模块&#xff0c;可以帮助开发人员更轻松地完成各种任务。其中包括Python的数学库&#xff0c;其中包括三角函数。 三角函数是最基本的数学函数…

断网了,还能ping通 127.0.0.1 吗?[localhost与127.0.0.1区别]

1.应用场景 主要用于学习了解localhost 与 127.0.0.1的区别&#xff0c; 本质. 以及计算机关于本机地址是如何工作的。 为什么要有这个地址。 2.学习/操作 1.文档阅读 断网了&#xff0c;还能ping通 127.0.0.1 吗&#xff1f; 开发环境- 配置虚拟主机域名/hosts文件 2.整理输…

反调试与反反调试

参考文本 (190条消息) C 反反调试&#xff08;NtQueryInformationProcess&#xff09;_(-: LYSM :-)的博客-CSDN博客 Windows 平台反调试相关的技术方法总结—part 2 - 先知社区 C/C MinHook 库的使用技巧 - lyshark - 博客园 (cnblogs.com) (177条消息) C 反反调试&#x…

哈工大2023春计算机系统大作业:程序人生-Hello‘s P2P

摘要&#xff1a;以hello.c程序为例&#xff0c;文章探究了从C语言代码文件到进程回收这一过程。基于Linux操作系统&#xff0c;运用gcc&#xff0c;edb等工具&#xff0c;详细介绍了程序编译的流程&#xff0c;分析了运行可执行文件时系统的进程管理与存储管理原理与机制&…

Transformer模型的基础演算

作者 | Quentin Anthony、Stella Biderman、Hailey Schoelkopf OneFlow编译 翻译 | 贾川、徐佳渝、杨婷 1 引言 Transformer语言模型的许多基本重要信息可以通过简单计算得出。不幸的是&#xff0c;这些计算公式在自然语言处理&#xff08;NLP&#xff09;社区中并不广为人知。…

DetectGPT:使用概率曲率的零样本机器生成文本检测

DetectGPT的目的是确定一段文本是否由特定的llm生成&#xff0c;例如GPT-3。为了对段落 x 进行分类&#xff0c;DetectGPT 首先使用通用的预训练模型&#xff08;例如 T5&#xff09;对段落 ~xi 生成较小的扰动。然后DetectGPT将原始样本x的对数概率与每个扰动样本~xi进行比较。…

Prompt工程探索

在开源大模型LLaMA等成熟后&#xff0c;目前业界焦点在于&#xff1a;如何才能让 LLM 按照我们的要求去做&#xff0c;也就是prompt工程&#xff0c;设计产生大量prompt训练语料用于微调大模型 设计原则 首先要说的是设计原则&#xff0c;主要包含以下几个&#xff1a; 清晰…

如何使用 ChatGPT 将任何数据格式导入 MySQL

ChatGPT 是 OpenAI 开发的强大语言模型&#xff0c;在各个领域都有广泛的应用&#xff0c;包括数据库开发。在本文中&#xff0c;我们将演示开发人员、DBA 和数据分析师如何利用 ChatGPT 的功能来增强向 MySQL 等数据库的数据导入。 如今&#xff0c;跨不同系统和格式的数据迁…

ChatGPT爆炸级更新,可以联网、使用插件进行交互

在几个月内ChatGPT一直处于科技热点的中心&#xff0c;并且放出了一个又一个大招&#xff0c;如GPT-4、深度融合进Office等等。前两天再次放出爆炸级更新--ChatGPT Plugins&#xff0c;让ChatGPT的躯体再次得到完善。 OpenAI将插件类比为ChatGPT的“眼睛和耳朵”&#xff0c;使…

ChatGPT王炸更新,插件系统上线!

Datawhale干货 最新&#xff1a;ChatGPT应用&#xff0c;来源&#xff1a;KiddoAI 文章编辑&#xff1a;Datawhale 这是一个"App Store"时刻 OpenAI今天宣布支持ChatGPT的新第三方插件&#xff0c;这个在网络上被热议的消息成真了&#xff01;这相当于苹果的App Sto…

chatgpt赋能python:使用Python制作动画的步骤和工具

使用Python制作动画的步骤和工具 Python不仅是一种流行的编程语言&#xff0c;还可以用于制作动画。本文将介绍一些基本步骤和工具&#xff0c;帮助你制作出精美的动画作品。 步骤一&#xff1a;选择一个好的动画框架 Python有很多强大的动画框架可以使用。其中一些最受欢迎…

chatgpt赋能python:Python动画引擎:如何实现流畅的动画效果?

Python动画引擎&#xff1a;如何实现流畅的动画效果&#xff1f; Python动画引擎是一个强大的工具&#xff0c;可以帮助开发人员快速创建出令人惊叹的动画效果。它可以用于制作游戏、建筑模拟、数据可视化等场景中&#xff0c;为用户带来更好的交互体验。在这篇文章中&#xf…

chatgpt赋能Python-python_chia

简介&#xff1a;什么是Python Chia&#xff1f; Python Chia是一种加密货币&#xff0c;它的挖矿过程使用Python编程语言。Python Chia是开源的&#xff0c;任何人都可以参与挖矿。 Chia使用绿色挖矿的方式&#xff0c;这意味着Chia的挖矿过程对环境没有任何负面影响。此外&…

美赛C题纪实

提示&#xff1a;这篇是美赛结束发的&#xff01;&#xff01;&#xff01;&#xff01;&#xff01;&#xff01;&#xff01;没有作弊&#xff0c;没有参考任何网上思路&#xff01;&#xff01;&#xff01;&#xff01;&#xff01;仅为自己记录教训和为他人提供代码案例 文…

让ChatGPT做我的Java老师,他会怎么教我学习Java呢?

最近ChatGPT挺火的&#xff0c;突然想到一个有趣的玩法&#xff0c;ChatGPT如果来当老师&#xff0c;他会怎么教我学习java语言呢&#xff1f; 首先来看看ChatGPT认为熟练掌握java语言需要多长时间呢&#xff1f; ChatGPT认为熟练掌握java语言需要3-6个月。那我们就让他给我一份…

基于Android的应用市场软件的设计

基于Android的应用市场软件的设计 摘  要 随着智能手机的普及&#xff0c;人们越来越依赖手机进行一系列操作。 由于Android系统是一款免费的操作系统&#xff0c;导致了使用Android系统的手机占到7成左右。为了让Android手机用户体验更好&#xff0c;就需要让Android手机用户…