* [ECOS] about timeslice and same priority thread switch. @ 2000-05-29 18:27 yyl 2000-05-30 14:47 ` Jonathan Larmour 0 siblings, 1 reply; 12+ messages in thread From: yyl @ 2000-05-29 18:27 UTC (permalink / raw) To: ecos [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain, Size: 541 bytes --] Hi, after finished building the ecos1.3.1 on Redhat linux6.1(target is pc x86),I use gdb stub and the example twothreads.c to test. From the doc ument and the code of kernel, I think the threads of same priority should switch by timeslice .But after comment the sentence in twothreads.c as followed:          cyg_thread_delay(200); I find no switch.Who can tell me why? I think the switch of thread invoked by dsr of real time clock interrupt.Is that right?  Thanks a lot.  ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [ECOS] about timeslice and same priority thread switch. 2000-05-29 18:27 [ECOS] about timeslice and same priority thread switch yyl @ 2000-05-30 14:47 ` Jonathan Larmour 2000-05-30 18:40 ` yyl 0 siblings, 1 reply; 12+ messages in thread From: Jonathan Larmour @ 2000-05-30 14:47 UTC (permalink / raw) To: yyl; +Cc: ecos > yyl wrote: > > Hi, after finished building the ecos1.3.1 on Redhat linux6.1(target is pc > x86),I use gdb stub and the example twothreads.c to test. > From the document and the code of kernel,I think the threads of same > priority should switch by timeslice.But after comment the sentence in > twothreads.c as followed: > cyg_thread_delay(200); > I find no switch.Who can tell me why? So you are saying that by changing the code to the following, it stops working? printf("Beginning execution; thread data is %d\n", message); /* cyg_thread_delay(200); */ for (;;) { delay = 200 + (rand() % 50); /* note: printf() must be protected by a call to cyg_mutex_lock() */ cyg_mutex_lock(&cliblock); { printf("Thread %d: and now a delay of %d clock ticks\n", message, delay); } cyg_mutex_unlock(&cliblock); cyg_thread_delay(delay); } Are you sure you didn't change anything in your configuration from the default that you didn't mean to? > I think the switch of thread > invoked by dsr of real time clock interrupt.Is that right? Yes. See Cyg_RealTimeClock::dsr() in kernel/VERSION/src/common/clock.cxx Jifl -- Red Hat, 35 Cambridge Place, Cambridge, UK. CB2 1NS Tel: +44 (1223) 728762 "Plan to be spontaneous tomorrow." || These opinions are all my own fault ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [ECOS] about timeslice and same priority thread switch. 2000-05-30 14:47 ` Jonathan Larmour @ 2000-05-30 18:40 ` yyl 2000-05-31 13:13 ` Jonathan Larmour 0 siblings, 1 reply; 12+ messages in thread From: yyl @ 2000-05-30 18:40 UTC (permalink / raw) To: Jonathan Larmour; +Cc: ecos [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain, Size: 3655 bytes --]  ----- Original Message ----- From: Jonathan Larmour < jlarmour@redhat.co.uk > To: yyl < ylyuan@csrd.org > Cc: ecos < ecos-discuss@sourceware.cygnus.com > Sent: Wednesday, May 31, 2000 5:47 AM Subject: Re: [ECOS] about timeslice and same priority thread switch. > > yyl wrote: > > > > Hi, after finished building the ecos1.3.1 on Redhat linux6.1(target is pc > > x86),I use gdb stub and the example twothreads.c to test. > > From the document and the code of kernel,I think the threads of same > > priority should switch by timeslice.But after comment the sentence in > > twothreads.c as followed: > >          cyg_thread_delay(200); > > I find no switch.Who can tell me why? > > So you are saying that by changing the code to the following, it stops > working?        It working.I mean the threads execute in the turn which they resume,but not switch by timeslice,ie,only the first thread finished ,the second thread can start.The code I modified as followed(I comment two sentences):      /*       cyg_thread_delay(200); */             for (i=0;i<=100;i + +) {          delay = 200 + (rand() % 50 )         /* note: printf() must be protected by a               call to cyg_mutex_lock() */            cyg_mutex_lock(&cliblock); {           printf("Thread %d: and now a delay of %d clock ticks\n",                 message, delay);             }           cyg_mutex_unlock(&cliblock);           /* cyg_thread_delay(delay); */   the result of the run:          Entering twothreads' cyg_user_start() function          Thread 0 and now a delay of 233 clock ticks           ...          ...          Thread 0 and now a delay of 225 clock ticks          Thread 1 and now a delay of 226 clock ticks          ...          ...          Thread 1 and now a delay of 238 clock ticks         I think the result should be:                   Entering twothreads' cyg_user_start() function          Thread 0 and now a delay of 233 clock ticks           ...          Thread 1 and now a delay of 226 clock ticks          ...          Thread 0 and now a delay of 233 clock tick           ...          Thread 1 and now a delay of 238 clock ticks           ...                        I didn't change anything in the configuration from the default .           Last I don't express clearly.I'm very sorry.           Thank you very much!   ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [ECOS] about timeslice and same priority thread switch. 2000-05-30 18:40 ` yyl @ 2000-05-31 13:13 ` Jonathan Larmour 2000-06-01 3:02 ` [ECOS] Configuration tool problem Alessandro Pinto 2000-06-01 22:31 ` [ECOS] about timeslice and same priority thread switch zhang 0 siblings, 2 replies; 12+ messages in thread From: Jonathan Larmour @ 2000-05-31 13:13 UTC (permalink / raw) To: yyl; +Cc: ecos > yyl wrote: > It working.I mean the threads execute in the turn which they > resume,but not switch by timeslice,ie,only the first thread finished ,the > second thread can start.The code I modified as followed(I comment two > sentences): > /* cyg_thread_delay(200); */ > for (i=0;i<=100;i + +) { > delay = 200 + (rand() % 50 ) > /* note: printf() must be protected by a > call to cyg_mutex_lock() */ > cyg_mutex_lock(&cliblock); { > printf("Thread %d: and now a delay of %d clock ticks\n", > message, delay); > } > cyg_mutex_unlock(&cliblock); > /* cyg_thread_delay(delay); */ > > the result of the run: > Entering twothreads' cyg_user_start() function > Thread 0 and now a delay of 233 clock ticks > ... > ... > Thread 0 and now a delay of 225 clock ticks > Thread 1 and now a delay of 226 clock ticks > ... > ... > Thread 1 and now a delay of 238 clock ticks > > I think the result should be: > > Entering twothreads' cyg_user_start() function > Thread 0 and now a delay of 233 clock ticks > ... > Thread 1 and now a delay of 226 clock ticks > ... > Thread 0 and now a delay of 233 clock tick > ... > Thread 1 and now a delay of 238 clock ticks > ... Ah, that happens because in each `for' loop, the majority of the execution time is spent in the printf function. printf is notoriously expensive. As a result, most of the time that a timeslice occurs, the mutex `cliblock' is locked, so the newly woken up thread cannot run; so it goes back to sleep again. Simply comment out the mutex lock and unlock calls in twothreads.c and you will see that things begin to behave slightly more sensibly. The mutex is completely unnecessary if the configuration option CYGSEM_LIBC_STDIO_THREAD_SAFE_STREAMS is enabled, which controls the existence of a mutex deeper inside libc stdio. Note that if you disable that configuration option as well, then the threads should then strictly alternate as you expected; however it also means there is a chance of them corrupting common data inside libc stdio since they can then interrupt each other at any point. Jifl -- Red Hat, 35 Cambridge Place, Cambridge, UK. CB2 1NS Tel: +44 (1223) 728762 "Plan to be spontaneous tomorrow." || These opinions are all my own fault ^ permalink raw reply [flat|nested] 12+ messages in thread
* [ECOS] Configuration tool problem 2000-05-31 13:13 ` Jonathan Larmour @ 2000-06-01 3:02 ` Alessandro Pinto 2000-06-01 8:03 ` [ECOS] " Jonathan Larmour 2000-06-01 22:31 ` [ECOS] about timeslice and same priority thread switch zhang 1 sibling, 1 reply; 12+ messages in thread From: Alessandro Pinto @ 2000-06-01 3:02 UTC (permalink / raw) To: Jonathan Larmour; +Cc: ecos-discuss Thank you a lot for your help yesterday, I compiled the gcc and all was ok. Now I need to create a the ecos RTOS to use the library and link it. When I try to run the configuration tool, the compilation results in the follow error: arm-elf-gcc -c -I//C/ecoslib/prova_install/include -I//C/PROGRA~1/REDHAT~1/ eCos/packages/hal/arm/arch/v1_3_1 -I//C/PROGRA~1/REDHAT~1/eCos/packages/hal/ arm/arch/v1_3_1/src -I//C/PROGRA~1/REDHAT~1/eCos/packages/hal/arm/arch/v1_3_ 1/tests -I. -I//C/PROGRA~1/REDHAT~1/eCos/packages/hal/arm/arch/v1_3_1/src/ - mcpu=arm7tdmi -Wall -Wpointer-arith -Wstrict-prototypes -Winline -Wundef -Wo verloaded-virtual -g -O2 -ffunction-sections -fdata-sections -fno-rtti -fno- exceptions -fvtable-gc -finit-priority -Wp,-MD,src/context.tmp -o src/hal_arm_arch_context.o file://C/PROGRA~1/REDHAT~1/eCos/packages/hal/arm/arch/v1_3_1/src/context.S file://C/PROGRA~1/REDHAT~1/eCos/packages/hal/arm/arch/v1_3_1/src/context.S: Assembler messages: file://C/PROGRA~1/REDHAT~1/eCos/packages/hal/arm/arch/v1_3_1/src/context.S:1 14: Error: undefined symbol CPSR_IRQ_DISABLE in operation file://C/PROGRA~1/REDHAT~1/eCos/packages/hal/arm/arch/v1_3_1/src/context.S:1 14: Error: undefined symbol CPSR_FIQ_DISABLE in operation file://C/PROGRA~1/REDHAT~1/eCos/packages/hal/arm/arch/v1_3_1/src/context.S:8 5: Error: Internal_relocation (type 187) not fixed up (OFFSET_IMM) file://C/PROGRA~1/REDHAT~1/eCos/packages/hal/arm/arch/v1_3_1/src/context.S:1 16: Error: Internal_relocation (type 187) not fixed up (OFFSET_IMM) make[1]: *** [src/context.o.d] Error 1 make[1]: Leaving directory `/c/ecoslib/prova_build/hal/arm/arch/v1_3_1' make: *** [build] Error 2 Can you help me? Bye AP ^ permalink raw reply [flat|nested] 12+ messages in thread
* [ECOS] Re: Configuration tool problem 2000-06-01 3:02 ` [ECOS] Configuration tool problem Alessandro Pinto @ 2000-06-01 8:03 ` Jonathan Larmour 2000-06-01 8:57 ` Alessandro Pinto 0 siblings, 1 reply; 12+ messages in thread From: Jonathan Larmour @ 2000-06-01 8:03 UTC (permalink / raw) To: Alessandro Pinto; +Cc: ecos-discuss Alessandro Pinto wrote: > > Thank you a lot for your help yesterday, I compiled the gcc and all was ok. > Now I need to create a the ecos RTOS to use the library and link it. > When I try to run the configuration tool, the compilation results in the > follow error: > > file://C/PROGRA~1/REDHAT~1/eCos/packages/hal/arm/arch/v1_3_1/src/context.S > file://C/PROGRA~1/REDHAT~1/eCos/packages/hal/arm/arch/v1_3_1/src/context.S: > Assembler messages: > file://C/PROGRA~1/REDHAT~1/eCos/packages/hal/arm/arch/v1_3_1/src/context.S:1 > 14: Error: undefined symbol CPSR_IRQ_DISABLE in operation [snip rest] Can you try deleting the file hal/arm/arch/v1_3_1/arm.inc in your build tree and trying the make again (which will recreate arm.inc). If it still doesn't work, please send us the arm.inc file. Jifl -- Red Hat, 35 Cambridge Place, Cambridge, UK. CB2 1NS Tel: +44 (1223) 728762 "Plan to be spontaneous tomorrow." || These opinions are all my own fault ^ permalink raw reply [flat|nested] 12+ messages in thread
* [ECOS] Re: Configuration tool problem 2000-06-01 8:03 ` [ECOS] " Jonathan Larmour @ 2000-06-01 8:57 ` Alessandro Pinto 2000-06-01 9:08 ` Jonathan Larmour 0 siblings, 1 reply; 12+ messages in thread From: Alessandro Pinto @ 2000-06-01 8:57 UTC (permalink / raw) To: Jonathan Larmour; +Cc: ecos-discuss The ecos build now is OK and I tried to compile some file automatic generated by VCC and all is OK. But I'm brave and I'm thinking to use an ARM instuction set simulator. This simulator need the RTOS library but the ones generated by the configuration tool (libtarget.a) doesn't work. There is the possibilities to compile the library for another compiler (in this case armcc by arm) ? THANKS AP ------------------------------------------------------------------ Alessandro Pinto Mobile: (+39)(0)3395366531 Address: Via L. Viani, 12 00125 Roma, Italy http://web.tiscalinet.it/alessandro_pinto/index.htm ------------------------------------------------------------------ ^ permalink raw reply [flat|nested] 12+ messages in thread
* [ECOS] Re: Configuration tool problem 2000-06-01 8:57 ` Alessandro Pinto @ 2000-06-01 9:08 ` Jonathan Larmour 0 siblings, 0 replies; 12+ messages in thread From: Jonathan Larmour @ 2000-06-01 9:08 UTC (permalink / raw) To: Alessandro Pinto; +Cc: ecos-discuss Alessandro Pinto wrote: > > The ecos build now is OK and I tried to compile some file automatic > generated by VCC and all is OK. > > But I'm brave and I'm thinking to use an ARM instuction set simulator. This > simulator need the RTOS library but the ones generated by the configuration > tool (libtarget.a) doesn't work. > There is the possibilities to compile the library for another compiler (in > this case armcc by arm) ? eCos uses features only found in GNU cc, so unfortunately that isn't an option worth pursuing. I believe the right way to go about running eCos with the ARMulator is to do a port of eCos to it. The reason is because eCos does not interwork with Angel on the boards, using the ROM monitor interface for I/O etc. To port eCos, the platform HAL would have to provide low-level communication with RDI/RDP. I don't know in detail how much work would be involved with that. We don't currently have plans to do it ourselves, so a contributed port would be welcome. Jifl -- Red Hat, 35 Cambridge Place, Cambridge, UK. CB2 1NS Tel: +44 (1223) 728762 "Plan to be spontaneous tomorrow." || These opinions are all my own fault ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [ECOS] about timeslice and same priority thread switch. 2000-05-31 13:13 ` Jonathan Larmour 2000-06-01 3:02 ` [ECOS] Configuration tool problem Alessandro Pinto @ 2000-06-01 22:31 ` zhang 2000-06-02 11:12 ` Jonathan Larmour 1 sibling, 1 reply; 12+ messages in thread From: zhang @ 2000-06-01 22:31 UTC (permalink / raw) To: Jonathan Larmour; +Cc: ecos-discuss > Ah, that happens because in each `for' loop, the majority of the execution > time is spent in the printf function. printf is notoriously expensive. As a > result, most of the time that a timeslice occurs, the mutex `cliblock' is > locked, so the newly woken up thread cannot run; so it goes back to sleep > again. > > Simply comment out the mutex lock and unlock calls in twothreads.c and you > will see that things begin to behave slightly more sensibly. The mutex is > completely unnecessary if the configuration option > CYGSEM_LIBC_STDIO_THREAD_SAFE_STREAMS is enabled, which controls the > existence of a mutex deeper inside libc stdio. > > Note that if you disable that configuration option as well, then the > threads should then strictly alternate as you expected; however it also > means there is a chance of them corrupting common data inside libc stdio > since they can then interrupt each other at any point. > > Jifl Hi,sorry to bother you again ,as you explained ,we change the value of CYGSEM_LIBC_STDIO_THREAD_SAFE_STREAMS from 1 to 0 in the file of ecos.ecc ,then we build the thread.c and run it ,but the result is the same , so ,we want to know whether we miss something to do or do not catch your real meaning. Moreover we also have some question on your explain.As your say , the majority of the execution time is spent in the printf function, it seems that the printf is the real cause of the unablity of thread switch ,however if we build another source file of two thread switch ,with one thread having lower priority and the other having higher ,the result is that they can switch .We are puzzled because this time the source file also contain printf, if the printf expense too much time as you said ,even if another thread have a higher priority ,the thread switch may not be realized either.So we are not sure ,will any body hints me ? Thanks a lot !! ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [ECOS] about timeslice and same priority thread switch. 2000-06-01 22:31 ` [ECOS] about timeslice and same priority thread switch zhang @ 2000-06-02 11:12 ` Jonathan Larmour 0 siblings, 0 replies; 12+ messages in thread From: Jonathan Larmour @ 2000-06-02 11:12 UTC (permalink / raw) To: zhang; +Cc: ecos-discuss zhang wrote: > Hi,sorry to bother you again ,as you explained ,we change the value of > CYGSEM_LIBC_STDIO_THREAD_SAFE_STREAMS from 1 to 0 in the file of ecos.ecc > ,then we build the thread.c and run it ,but the result is the same , > so ,we want to know whether we miss something to do or do not catch your > real meaning. Did you also comment out the mutex lock/unlock lines? Otherwise disabling that option will have no effect. But it turns out I missed out that there is yet another mutex lock buried deep in the serial code (called from serial_write() specifically). So even with the above option disabled, *and* the mutexes removed, it is still possible for the threads to not strictly alternate on a timeslice, because one of them is holding that mutex. But it will be a lot closer. Try it and see. > Moreover we also have some question on your explain.As your say , the > majority of the execution time is spent in the printf function, it seems > that the printf is the real cause of the unablity of thread switch > ,however if we build another source file of two thread switch ,with one > thread having lower priority and the other having higher ,the result is > that they can switch .We are puzzled because this time the source file > also contain printf, if the printf expense too much time as you said > ,even if another thread have a higher priority ,the thread switch may not > be realized either.So we are not sure ,will any body hints me ? It depends on the exact code you are using, but my guess is that in this case the threads are not being timesliced. Instead they are being scheduled strictly according to their priorities, with the possibility of there also being mutex priority inheritance. Without seeing the code you are using I can't be sure. Jifl -- Red Hat, 35 Cambridge Place, Cambridge, UK. CB2 1NS Tel: +44 (1223) 728762 "Plan to be spontaneous tomorrow." || These opinions are all my own fault ^ permalink raw reply [flat|nested] 12+ messages in thread
[parent not found: <3.0.5.32.20000601192104.00a1e630@mailhost>]
* Re: [ECOS] Re: Configuration tool problem [not found] <3.0.5.32.20000601192104.00a1e630@mailhost> @ 2000-06-01 10:47 ` Alessandro Pinto 2000-06-01 12:37 ` Jonathan Larmour 1 sibling, 0 replies; 12+ messages in thread From: Alessandro Pinto @ 2000-06-01 10:47 UTC (permalink / raw) To: Alfredo Knecht; +Cc: ecos-discuss Dear Alfredo, I think that the problem is not the mount. I had this problem but I resolve it in a strange way. First of all are you sure that you have the the Cygwin B20 release? Remember to patch the gcc before configure it. I hope that this can help you. ------------------------------------------------------------------ Alessandro Pinto Mobile: (+39)(0)3395366531 Address: Via L. Viani, 12 00125 Roma, Italy http://web.tiscalinet.it/alessandro_pinto/index.htm ------------------------------------------------------------------ ----- Original Message ----- From: "Alfredo Knecht" <aknecht@cimsi.cim.ch> To: <ecos-discuss@sourceware.cygnus.com> Cc: <apinto@parades.rm.cnr.it>; <jlarmour@redhat.co.uk> Sent: Thursday, June 01, 2000 7:21 PM Subject: [ECOS] Re: Configuration tool problem > Dear all, > > after mounting a textmode point, i still get the same error from make: > > Makefile:89: *** commands commence before first target. Stop. > make[1]: Leaving directory `/tmp/build/gcc/gcc' > make: *** [all-gcc] Error 2 > make: Leaving directory `/tmp/build/gcc' > bash-2.04$ > > #these are my mounts: > bash-2.04$ mount > Device Directory Type Flags > G:\GPS\APPS\cygw / user textmode > G:\GPS\APPS\cygw /c user textmode > G:\GPS\APPS\cygw /j user textmode > > What a I doing wrong? > > Thanks, Alfredo > > > >The ecos build now is OK and I tried to compile some file automatic > >generated by VCC and all is OK. > > ************************************************************************ > Alfredo Knecht Fax ++41 91 610 8970 Tel ++41 91 610 8960 > SUPSI-ICIMSI aknecht@cimsi.cim.ch http://www.cimsi.cim.ch > > Istituto CIM della Svizzera italiana CH-6928 Manno (Lugano) > ************************************************************************ ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [ECOS] Re: Configuration tool problem [not found] <3.0.5.32.20000601192104.00a1e630@mailhost> 2000-06-01 10:47 ` [ECOS] Re: Configuration tool problem Alessandro Pinto @ 2000-06-01 12:37 ` Jonathan Larmour 1 sibling, 0 replies; 12+ messages in thread From: Jonathan Larmour @ 2000-06-01 12:37 UTC (permalink / raw) To: Alfredo Knecht; +Cc: ecos-discuss, apinto Alfredo Knecht wrote: > > Dear all, > > after mounting a textmode point, i still get the same error from make: > > Makefile:89: *** commands commence before first target. Stop. > make[1]: Leaving directory `/tmp/build/gcc/gcc' > make: *** [all-gcc] Error 2 > make: Leaving directory `/tmp/build/gcc' > bash-2.04$ > > #these are my mounts: > bash-2.04$ mount > Device Directory Type Flags > G:\GPS\APPS\cygw / user textmode > G:\GPS\APPS\cygw /c user textmode > G:\GPS\APPS\cygw /j user textmode > > What a I doing wrong? Nothing :-/. I've been trying to find the best workaround for what is actually a cygwin bug. Okay. Let's try a different approach. Please download the May 25th snapshot of the cygwin1 DLL from http://sourceware.cygnus.com/cygwin/snapshots/ i.e. cygwin1-20000525.dll.gz Uncompress it with "gunzip cygwin1-20000525.dll.gz" and then exit all your running cygwin applications. Now go to the "bin" subdirectory of your cygwin installation and rename "cygwin1.dll" to "cygwin1.dll.old". Now copy in the uncompressed cygwin1-20000525.dll and rename that to cygwin1.dll This should fix the problem and you can continue. Note that snapshots after the 25th May and up to (at least) the 31st May definitely do not work - they are very broken in other ways - so do not install those. I have been patiently waiting for the cygwin team to produce an official 1.1.2 update to the cygwin DLL which includes this bug fix, but unfortunately it still hasn't happened. Let me know how it works out. Jifl -- Red Hat, 35 Cambridge Place, Cambridge, UK. CB2 1NS Tel: +44 (1223) 728762 "Plan to be spontaneous tomorrow." || These opinions are all my own fault ^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2000-06-02 11:12 UTC | newest] Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2000-05-29 18:27 [ECOS] about timeslice and same priority thread switch yyl 2000-05-30 14:47 ` Jonathan Larmour 2000-05-30 18:40 ` yyl 2000-05-31 13:13 ` Jonathan Larmour 2000-06-01 3:02 ` [ECOS] Configuration tool problem Alessandro Pinto 2000-06-01 8:03 ` [ECOS] " Jonathan Larmour 2000-06-01 8:57 ` Alessandro Pinto 2000-06-01 9:08 ` Jonathan Larmour 2000-06-01 22:31 ` [ECOS] about timeslice and same priority thread switch zhang 2000-06-02 11:12 ` Jonathan Larmour [not found] <3.0.5.32.20000601192104.00a1e630@mailhost> 2000-06-01 10:47 ` [ECOS] Re: Configuration tool problem Alessandro Pinto 2000-06-01 12:37 ` Jonathan Larmour
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).